Crash when ISceneNode deleted by user

vi-wer · Post by **vi-wer** » Thu Feb 21, 2008 6:11 pm

Thanks for the code but actually I had another idea how to solve this: not use Irrlicht at all (that should work for sure).
Just kindding

I see threre is no way to solve this without making even more trouble.
My own idea was to make an intelligent reference class which knows what to do by default but I guess that will take some time.

rogerborg · Post by **rogerborg** » Fri Feb 22, 2008 9:03 am

I'm actually coming round to thinking that perhaps we should do something about it. It's a bit nasty to have reference counted objects that don't actually know whether they can delete themselves. We've currently got a situation where the owner implicitly just doesn't drop() some objects, which makes me a bit uncomfortable.

vi-wer · Post by **vi-wer** » Fri Feb 22, 2008 2:57 pm

I think your 2nd suggestion about creating a reference counted object with a default value of 0 would be a nice pointe to start. As far I know all objects in Irrlicht which might need a reference count are created with createSomething, addSomething or getSomething. So it should not be a big deal to grab() them there. All other objects which are created by the user with new would have to be grabbed explicitly.
Another possible solution for this, that is maybe more safe, could be an IReferenceCounted class which asks how the object has been created by a bool parameter in the constructor (this would have to be added to all derived classes constructors).

vi-wer · Post by **vi-wer** » Fri Feb 22, 2008 7:26 pm

Ok, forget everything from before. Simple things are still the best:

Code: Select all

		//! Destructor.
		virtual ~IReferenceCounted()
		{
		    // reference counted object destroyed improperly
		    if( ReferenceCounter > 1 )
		    {
		        printf("warning: incorrect destruction of IReferenceCounted object, used by %i\n",ReferenceCounter);
		        printf("--object name: %s\n",DebugName);
		    }
		}

This way it should not matter how the object has been created whether on the heap or the stack. Removing it with a reference count of 1 doesn't harm anyone. But if it's used by more than one it will warn the user about unresolved references and help to find the problem.
Any objections?

I also thought about an extra virtual function for this class which could provide more detailed information such as name, id or type of the derived class but I guess getDebugName is something similar.

Acki · Post by **Acki** » Fri Feb 22, 2008 8:30 pm

but getDebugName only returns the name if Irrlicht was compiled in debug mode !!!