I’ve got a TArray which I’m populating with instances of custom class like this:
octaves.Push(new planetOctave());
I’ve heard the rule is that for every new you must have a delete.
If I just pop the last element from the TArray like this:
octaves.Pop(true);
It doesn’t call the destructor in the object which tells me that it’s only the pointer in the TArray being deleted when I need the object to be deleted from memory too.
my planetOctave class is not extended from a UE4 class so it doesn’t qualify for garbage collection, what’s the right way to clean up after this little fellow?
I would recommend not using raw new. especially if you are using ue4 already (TArray), and also most people have modern c++ compilers anyway so raw new shouldnt even be used anymore. look into smart pointers and apply the proper one, there are ue4 ones and standard ones.
I disagree. Raw new is totally fine, but it depends more on what you’re doing. I would never use smart pointers with large numbers of objects where speed/performance was a concern, for example.
While, i agree with the first statement, that is expert territory in terms of today’s C++. I can’t generally recommend expert level things on a public forum where people will use this as a resource. If you understand that smart ptrs are slower, than you probably already understand the risks associated with handling your own memory.
Also idk about ue4, but the standard ones have been heavily optimized. They are used all the time in large scale where speed and performance is concerned, at least in my experience as a consultant.
Out of interest, anyone know why you (as far as I can see) have to write MakeShareable< X >(new X(a, b, c)) (at least the <X> is optional, I got really tired of that with long UE4 type names until I realized), but you can write MakeUnique< X >(a, b, c), which seems a lot more sensible?
And while I’m here, it seems you can’t use a forward declared class with TUniquePtr. Is there a good reason for that? Can’t remember if stl is the same.
Well, there’s a different use case for them all. I am just going to link a stackexchange question, as there’s a bit of information and im lazy. It has only one answer, but i think it’s very clear and concise.
*the question refers to QT but ignore it, the answer speaks volumes about the uses and limitations of each type of memory management.
[SIZE=2]Question: Does anyone know limitations with using say something like TMap with std memory management, i was told that this was the best use case as of 4.12, but epic has provided systems for it. so they didn’t just add it to add it. there is a reason it exists but idk if it matters anymore or not. so i guess what im asking is what should we be using for the most portability ? I would imagine the ue4 implemented ones, but someone (i forgot now) told me that they had better success across some platforms [/SIZE]with std ones.