Okay, so, it’s good to know the UObject approach is working.
I’m not clear on how you’re trying to use FGCObject. First off, you realise that by overriding UObject/AActor::GetReferencedObjects, you have no need for FGCObject in this instance? Assuming you’re just trying to see how to use it…
Imagine you had the following struct
struct FMyStruct
{
TSet< UMyContainedObject* > MySet;
}
And embedded it in some other UObject derived class
UCLASS()
class UMyOuterObject: public UObject // or AActor/whatever
{
GENERATED_BODY()
...
FMyStruct Str;
}
So your outer class indirectly contains a set of UObject pointers. You could protect these in the same way as above, by overriding AddReferencedObjects in UMyOuterObject, and adding Str.MySet to the collector. Problem is, you’d have to duplicate the code for every object that embedded an FMyStruct. You’d have further problems if you wanted a global FMyStruct, etc.
This is where you should use FGCObject.
struct FMyStruct: FGCObject
{
TSet...
virtual void AddReferencedObjects(FReferenceCollector& Collector) override
{
Collector.AddReferencedObjects(MySet);
}
}
Note that in the case of FGCObject, you don’t call the base class implementation of the method in your override, as it doesn’t have one.
So now the referencing is encapsulated in your struct, so no matter how or where you create an FMyObject, the set members will always be referenced properly. The unreal code does know about your object automatically - if you look at FGCObject constructor and destructor, you can see it registers the instance with the garbage collection code. Also in the UObject case, so long as the outer object is referenced (as it will be unless you’re doing something unusual) the set elements will be correctly cleaned up once the outer object ceases to exist.
You know, in my first post I was asking for such a tutorial, I might just end up being the one to write it, there’s certainly a need. I’ll do a bit of testing and if I’m confident enough that I understand how it works, I’ll give it a go.
