If you’re making something that needs to exist at game time, needs to be serialized…etc use UObjects. If you just want to store UI state and work with Slate, use plain old C++ objects. Take a look at TSharedPtr, TSharedRef, TWeakPtr, those are how we avoid leaking memory for plain old C++ objects. In fact in order to display a list of objects in slate slate requires you provide a TArray of TSharedPtr objects or UObjects.
Cheers,
Nick
I’m really rusty on C++ and am concerned that I’m going to end up with a ton of memory leaks as a result. Anyway, I’m trying to create a list of objects that will be displayed in a table via slate but am uncertain how I should go about coding up the objects. The example I’m using as a reference is the Message Debugger. In it, it defines various structs, all of which have names similar to InfoPtr.
My original thought was to use UObjects, but have a gut feeling that isn’t a good idea and could be a nightmare as far as instancing goes. What would be the best practice for coding up objects that will be utilized in this manner?
On another note, I want to create these objects in the core module of my plugin and utilize them in the editor module. I don’t think this should complicate the issue, but wanted to throw it out there just to be on the safe side.