how can i call a destructor from inside the class?
i'm working on a game and i wan't to delete a monster once it reaches a certain location on the screen.
how can i call a destructor from inside the class?
i'm working on a game and i wan't to delete a monster once it reaches a certain location on the screen.
Well if your class contains
monster *m;
Birth is something like
myvar->m = new monster;
Then follows some moving around until the magic place is reached, at which point you do
delete myvar->m;
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
an object can call some cleanup code on itself, but should never destroy itself (and cannot, that i'm aware of). some other object should probably own or control the monster object, and should take care of deleting it.
Environment: OS X, GCC / G++
Codes: Java, C#, C/C++
AOL IM: neandrake, Email: neandrake (at) gmail (dot) com
It can certainly be done, particularly in the context of intrusive ref-counted objects.
I wont be telling you how though until you can show what you are actually doing and that you really do need to do this after all. Otherwise I'd be loading a gun, cocking it, pointing it at your foot, and placing your finger on the trigger.
More info please.
My homepage
Advice: Take only as directed - If symptoms persist, please see your debugger
Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"
Usually, you need to control the lifetime of the object.
If you have allocated the new object with new, use a smart pointer. Then make sure it goes of of scope when it you need it no longer. That's basics.
Don't destroy the object internally.
But it wouldn't hurt to elaborate a little.
Hehe. Very nice analogy.Otherwise I'd be loading a gun, cocking it, pointing it at your foot, and placing your finger on the trigger.
Wouldn't this the be same condition as if you just outright killed the monster? I won't define them for you but these are the functions I use
just swap the Monster.Collide() with any condition you want and use a boolean to control the return value of Dead().Code:if(!Monster.Dead()) Monster.Handle(); ................. if(Monster.Collide(Bullet)) Monster.Kill();
and if I wanted to set his Death to trigger because of him moving to far.. I'd do so in his MoveBehavior() function.
Last edited by Lesshardtofind; 09-12-2010 at 11:00 PM.
Monster.Kill would set the monster's death status. If you want to remove the monster object, there should be something like Game.RemoveMonster(aMonster).
Environment: OS X, GCC / G++
Codes: Java, C#, C/C++
AOL IM: neandrake, Email: neandrake (at) gmail (dot) com
Agreed but usually in a level with one monster I have a few like it and rather than create 7 different class declarations for the same monster I make one or two for each type and recycle them. Giving them different .Revive() conditions and then clearing them up after the level. So its not deleted until its not going to be potentialy used. This this a bad tactic?
if every monster of the same type is always in the same location, always has the same hp, always has the same [other stat], then what you're doing is fine, other than that you have to have separate instances in some manner. how many monsters on a level are we talking? if the monsters are going to be in and out like crazy, you could create a monster memory pool (allocate a pre-calculated/guessed number of monsters in advance). alternatively, you could try not deleting the monster until the level is deleted, but just have another boolean for the monsters - you already know if they're dead using isDead
Environment: OS X, GCC / G++
Codes: Java, C#, C/C++
AOL IM: neandrake, Email: neandrake (at) gmail (dot) com