What's wrong with this code?

[ShiftZ]

@Limanima

I think it’s a good idea and even mandatory to have GC. Wouldn’t it be a nightmare to manage pointers and objects lifetimes? That would be completely unmanageable in a complex software.

Unreal Engine is the only engine I know with GC. Nobody in his right mind will introduce GC to a C++ engine.
GC solves kind of problems that were relevant 15 years ago. C++11 introduced standart smart pointers implementation that solve all the problems GC solves. But GC in Unreal Engine was introduced before C++11 implementation become widely available on Windows platform.
Now GC is the problem, but it can not be undone. It’s a curse, not bless.

@Limanima

So it’s possible that the pointers stored in the array become NULL by magic and a check for NULL should be made.

Yes, they can be nullified. But in the test code there is no visible pointers to the reflection system. Simply adding UPORPERTY() on top of TArray declaration in the global scope doesn’t make it magically visible to a reflection system. It works only with reflected objects of properly declared classes.

@Emaer

This clearly implies who owns and who is responsible for the lifetime of the object.
If you need to share a given resource then you use shared_ptr,
If it is exclusive to a given object then unique_ptr.
If you are just observing (without transferring ownership) then weak_ptr. And only weak_ptr really needs to be checked for null.

GC completely ruins this logical, widely used approach.
And more. This leads to four different pointer types inside one project:

Now that one deserves my grateful respectful attitude.
I couldn’t have said better.
I can only add that GC ruins RAII idiom. If one doesn’t know what it is or does not respect it, he doesn’t know the first thing about software engineering on C++.