I had always assumed that TStrongObjectPtr
worked similarly to TSharedPtr
in that it keeps an internal reference count. But it appears that it works more like TUniquePtr
in that it takes exclusive ownership over the UObject
.
So if you have two TStrongObjectPtr
s referring to the same UObject
and one of them goes out of scope, the other one now has a dangling pointer. Unless I misunderstand the code, this is because the base class GCObject
unregisters the object in its destructor.
The copy constructor and copy assignment operators of TStrongObjectPtr
do not take this into account though, so it’s easy to end up in this situation.
Am I on the wrong track here? If not, those copy operations should be removed