Heap allocations

[Xaryl]

From the user point of view, the only difference between the pointers from create...(...) and add...(...) is that the pointer from create...(...) needs to be drop()-ed an extra time.
(so yes, you can safely grab() and drop() both.)

Internally, in addImage(...), a GUIImage is allocated with new (counter=1).
It is then added to the GUI tree and grab()-ed (counter = 2).
Next the gui environment drop() it one time before returning the pointer (counter=1). <== this step is the main difference between add and create
And finally, when it is removed from the GUI tree, it would be drop()-ed (counter=0 and deleted).

For the create...(...) functions, the pointer is not used/grab()-ed elsewhere, and thus the engine can't drop() the pointer one time before returning it to the user (or the counter becomes 0 before returned).

[kekar]

Thanks for that clarification Xaryl!

I've done a few tests like the following code. It's the only thing run in the main function and it uses some part of my API towards Irrlicht. BMUCtxInst::instance() is just a singleton that gives access to the Irrlicht initialized API (ensured to be initialized one *once)..

Code: Select all

 
// Alloc test
 
BMUCtxInst& Ctx = BMUCtxInst::instance();
scene::ISceneManager& Scene = Ctx.getSceneManager();
BM_ASSERT(0 != Scene.getGUIEnvironment());
                
while (true)
{
                video::ITexture* const Texture = Ctx.getVideoDriver().getTexture(BM_MEDIA_BRAIN_ICON);
                BM_ASSERT(0 != Texture);
 
                gui::IGUIImage* const Img = Scene.getGUIEnvironment()->addImage(Texture, position2d<bm_int>(0,0), true);
                BM_ASSERT(0 != Img);
 
                Img->drop();
}
 

My problem is, it still seems to leak a lot. The process seem to grow the whole time (approx. 3MB/sec). I'm not sure why.

[serengeor]

shouldn't you call remove on image instead of drop?

[kekar]

Hm, yes, that seems to solve it..

[CuteAlien]

Yes do use remove() and don't call drop on it (as you did not grab and added it with an add function). In case you wonder why you have to call remove here ... you remove the element from the GUIEnvironment with that (which means it is no longer rendered). The gui-environment itself also does do grab()'s and drop()'s internally as every class that handles objects should do, but you should in this case rather think of it as removing it from the GUI and not having to care about memory.

Textures are a special thing. Unless you remove them explicitely from the cache they are not deleted automatically before the program closes.

[Brkopac]

Its really simple, you're trying to over complicate things. If you use any function that begins with "create" YOU are responsible for dropping it at some point (whether that be at the beginning, middle, the vortex, the end of the application). The methods with "create" ARE NOT being handled "under-the-hood", where as the "add" are.

Example A:

Code: Select all

// This pointer is not managed by irrlicht in any way shape or form (you have used new)
IrrlichtDevice *device = createDevice (video::EDT_DIRECT3D9);
 
// You own this memory, you have to drop it (the equivalent of delete)
device->drop();

Example B:

Code: Select all

scene::IAnimatedMesh *mesh = device->getSceneManager()->getMesh ("mesh.obj");
 
// This is pointer is now managed by irrlicht, when it cleans up it will attempt to refCount--
scene::IAnimatedMeshSceneNode *node = device->getSceneManager()->addAnimatedMeshSceneNode (mesh); 
 
// This will cause the memory to be cleaned up, but the pointer could still be referenced inside of irrlicht somewhere, undefined results.
node->drop();

Brkopac

[kekar]

Thanks for additional information, it's really appreciated!

Yes, it's the way I originally/vaguely thought it was, but I wasn't 100% sure. The documentation do say explicitly/clearly state that you're totally responsible for the reference count of heap objects to they gets deleted when making new objects with "create*" method.