I’m pretty sure this is a bug, and if so a pretty significant one. Luckily it also appears to be easy to fix.
FGCObject works by registering instances on construction and unregistering on destruction. However, only the default constructor is implemented. This does not deal with the case of FGCObject-derived objects being copy-constructed, since the compiler generated copy-constructor does not invoke the default constructor. I was constructing an object, then adding it to a container and then the original temporary was being destroyed. The container copy was not registered and so my references were being garbage collected.
I added the following to my github build and now it behaves as expected.
Although FGCObject was not meant to be used this way, your suggestion makes sense. There’s only one problem with your code: constructor forwarding is not supported by all compilers supported by UE4.
Hi Robert.
That’s true, though of course it could be trivially refactored into an Init method.
Could you explain what you mean by “FGCObject was not meant to be used this way”? Obviously there’s not a great deal of documentation to tell us how it is meant to be used. Is there some fundamental reason why FGCObjects should always be created on the heap? Even if that is the case, surely the copy constructors should still be disabled if copying is not desired? Currently, not only will copying fail to behave as expected wrt references, but the copy will also attempt to unregister itself on destruction, despite never having been registered.
Thanks.
I made the change about two weeks ago (master branch).
There’s no 'fundamental reason - FGCObject used to be used only as heap allocated object, this was more a guideline related to how UObjects work themselves rather than any particular limitation.
As I said, your suggestion makes sense though, now that FGCObject is used more in runtime code (IIRC its roots come from the editor) it makes sense make it more robust.