It seems to me like any memory allocated inside Iw2DInit() and Iw2DTerminate() must be also released inside these functions - mo matter if it is related somehow to Iw2D. Is it true?
I was solving strange problem within last hour. Airplay was throwing up an assertion like this one
IwAssert failure (MEMORY, 1573)
Bucket 0(System) is still in use....
Finally I found it was an allocation inside container class (similar to std::vector) that happen when pool was about to grow up. When I destroyed the memory pool manually (instead of let it to destructor) before Iw2DTerminate() the assertions disappeared.
I am quite sure the container class itself is fine. In other cases I am calling grow up method many times within game loop without any problem. The problem was only with those instances of that class that persist Iw2DTerminate().
Well, it looks I am asking the problem that I already solved, I just want to be sure :-)
Thank you in advance for answer.
Yes, there's an explanation here: https://www.airplaysdk.com/node/1091
Mark,
thank you for your answer as well as your explanation. That was what I thought.
In my personal opinion Airplay shouldn't do things like this. It is very confusing (at least for me) and such behavior doesn't seem to be standard. Even if I appreciate what your memory manager is doing for me the memory allocation and deallocation should be entirely in my hands. No module (that is not even related to memory management nor to memory I have allocated) should tell me how to treat memory in my app.
I kind of agree, but the memory tracking is normally worth it (and invisible apart from this one edge case). Ideally we'd initialise the memory manager before static constructors and wait until after static destructors to release the memory pool, but that's difficult to achieve for various reasons. IwGx etc. bring this up so they can use the debug heap more easily.