Is it ok to use UE objects in non-UE classes?

Development Programming & Scripting
1

Not sure, what you mean by GO…

In general I don’t see any problems. I don’t know either what you’re planning to do with your non-UE-class… just keep in mind that you might leak memory, but as long as your class compiles and runs… why should there be a problem?

2

Is it ok, to use UE-class based objects ( like UObject, AActor etc ) in non UE-based classes/structs, ie:

class Foo
{
    FName name;
    UObject object;
}

I know, that using pointer to UE object would be a killer for GC, but what about holding it by value like in this example?
Thanks.

3

Sorry - it was supposed to be GC ( garbage collector ). I’m trying to fix bug in some third party plugin that seems to have memory leeks, and it already implemented convensions like I indroduced. I’m just trying to find something in there.

4

Mh, I’m not sure if the current c++ standard has already an optional GC included. if you’re not using any smart pointers you have to handle it yourself. Have you tried a leak detector to determine what’s causing the leaks?

5

Hi,

You should not deal with UObjects in terms of their value, and that includes having a direct data member of one. You may get it to compile, but UObjects are not designed to be used as value types and are not supported to be used in this way.

However, UObjects referenced by non-UObjects can be made aware to the GC, if you inherit FGCObject and override the AddReferencedObjects member function, e.g.:

class Foo : public FGCObject
{
public:
    virtual void AddReferencedObjects(FReferenceCollector& Collector) override
    {
        Collector.AddReferencedObject(object);
    }

private:
    FName name;
    UObject* object;
};

This will ensure that this pointer is treated as a strong reference by the GC, including automatically nulling it out if the object is marked as pending kill.

Hope this helps,

Steve

6

@ thanks for idea. I didn’t know about this class. What I did, was converting some of the structs and classes that were there into UCLASS / USTRUCT and adding UPROPERTY to pointers based on UObjects. It actually didn’t work, but what did, was making TWeakObjectPtr out of those objects. Now everything works =]

7

Cool. :slight_smile: One thing to note though is that FGCObject-derived types are not usable in our containers. That’s fine if you only heap allocate these objects or create them on the stack, but if you do, you might want to consider TStrongObjectPtr as an alternative:

class Foo
{
    FName name;
    TStrongObjectPtr<UObject> object;
};

There is some overhead involved in using TStrongObjectPtr though - if you have multiple pointers in your type that need to exposed to the GC, the FGCObject route is still preferable (with the caveats I mention).

Steve