I have worked with Irrlicht API in c++ for over a 1/2 year now. I do understand the concept with grab() and drop(), generally, but I really wonder about these areas of the API;
Since the documentation states that all methods with the prefix "create*" must be handled with grab and drop, I wonder how these objects are handled in their lifespan? I assume these also are heap allocations.. When this is called, how is the object memory allocation handled? The documentation in Irrlicht states that you should not call drop() (and grab()) for these calls of the API.
\return Pointer to the created image element. Returns 0 if an error occurred. This pointer should not be dropped. See IReferenceCounted::drop() for more information. *
kekar wrote:The documentation in Irrlicht states that you should not call drop() (and grab()) for these calls of the API.
No. It doesn't say you should not grab() these objects.
Actually you are even supposed to drop() and object if you did a grab() by yourself.
The reason why there are things that should be dropped and things that should not be is that some things (like textures) are managed by other things (in this case the VideoDriver) and you would mess things up if you destroy something the driver is relying on.
Software documentation is like sex. If it's good you want more. If it's bad it's better than nothing.
I don't get it, if you *do* call grab(), for pointers delivered by these methods, how can the reference counter be balanced? It clearly states in the documentation that you explicitly should *not* call drop, when calling these parts of the API.
You should not call drop if you did not call grab before. If you did you have to call drop. Read through the documentation of IReferenceCounted to clarify this.
Software documentation is like sex. If it's good you want more. If it's bad it's better than nothing.
Or, do they actually allocate these things into the heap memory for the whole lifespan of the process? E.g. if a previously call has been done, a new exact call, anywhere (object instances), it will reuse the previously allocated data in memory? Meaning, that it isn't released before the process goes down, but reused the whole time, in-depended of it being used or not by other objects..?
Simple put all the reference counting stuff is a simple new/delete. There is no magic. It simply ensures that no object is deleted that is still needed somewhere.
Software documentation is like sex. If it's good you want more. If it's bad it's better than nothing.
Sylence wrote:You should not call drop if you did not call grab before. If you did you have to call drop. Read through the documentation of IReferenceCounted to clarify this.
Thanks for your help. But a simple question, why is it stated in the documentation that you SHOULDN'T call drop()? If I grab() a heap object, in my mind, I must release it with drop(), which means, if you should NOT call drop(), it implies to me that grab() is not to be called either. I just want to know, how do we don't get memory leaks when not using the reference system in Irrlicht for methods not prefixed with create*.
As i said previously: this statement is only true until you call grab. If you actually called grab you have to call drop (despite the documentation saying the opposite) to prevent memory leaks.
Software documentation is like sex. If it's good you want more. If it's bad it's better than nothing.
Ok, so let's get this clear.. The documentation is not accurate, it's even, *way* vague/bad/misleading.
From: IGUIImage* addImage(..) // No CREATE label..
\return Pointer to the created image element. Returns 0 if an error occurred. This pointer should not be dropped. See IReferenceCounted::drop() for more information. */
when you create an object in the Irrlicht engine, calling a method which starts with 'create', an object is created, and you get a pointer to the new object. If you no longer need the object, you have to call drop().
Reference counts-depended allocations in heap does NOT *just* concern methods in the *Irrlicht-API* that not start with create*(..), which the documentation clearly states all over..
Well I understand 'dropped' as calling drop on it when there are no more references. Otherwise it's just using the reference counting mechanism as it was intended to be used.
Software documentation is like sex. If it's good you want more. If it's bad it's better than nothing.
I know drop() isn't supposed to be called if you don't call grab().. But the docs. just states, simply, DON'T call drop on this call.. My question is, is the documentation faulty?
So, in these parts of the documentations, the 'dropped'-statment just means that you shouldn't explicitly call "C++ delete" on it? I would *never* do that from objects ptrs. delivered from Irrlicht..
So the conclusion is, the Irrlicht-API functions that you call OTHER methods, without "CREATE"-prefix, *do require* that you to manage the allocations with the reference counter with the API, especially if you are the only user (object) using this, otherwise memory leaks would happen..
I think (though might be wrong) that objects created with 'create' functions are not managed by irrlicht's managers when they are created, so the user is responsible for dropping them.
The documentation clearly states that method starting with "create.*" must be handled with grab() and drop(), but I'm not sure if this is the case for other objects, if you for instance call "addImage(...)", you need to handle the reference count too, or you'll end up with a leak. I'm not sure 100% yet how these are in practice handled within the API..
