quote:Original post by BriTeg Hokey crap, I''ve led you down the garden path. I whipped up a quick test program, and it looks like I was completely wrong. The derived class''s destructor *will* call the base class destructor, regardless if it is virtual or not. This is not how other member functions work, I guess it''s only for the destructor.
So, forget everything I said. Delete your stuff in your base class destructor (or even keep that protected cleanup function, it''s handy if you want to reset your object without destroying it), and make your derived contructor completely empty (unless the derived class does extra memory allocation of its own).
Sorry again for the wrong information, I feel bad.
Lol. It''s OK. Thx for the help anyway. I would probably have been sleeping(Midnite now) if you had not replied to my post and i would never have solved this.
quote:Original post by rodzilla Let''s take an example : class B inherits from A.
Whether the destructors are virtual or not, whenever B::~B() is called, A::~A() is called right after. So you do NOT have to reimplement A::~A() in B::~B().
Now, here''s what the virtual destructor changes. Say you write the following code :
A* a = new B();
delete a;
If both destructors are virtual, "delete a" will invoke B::~B(). If they are not, "delete a" will invoke A::A() (which is probably not what you want).
There is a simple rule : if there are virtual methods in a class (or in its base class) the destructor must be defined virtual.
Hope it helps.
So virtual deconstructors are only required if you use polymorphism in ur app?
Im not comfortable with polymorphism and i cant think of a reason why anyone would need it when inheritance can do it.It would be nice to tell me the advantages of polymorphism over inheritance.
Only one rule : whenever you use virtual methods, the destructor must be virtual.
As for using polymorphism, say you have "drawable" things. Some "drawable"s will be, say, "model"s. Other "drawable"s could be, say, "particle_systems".
When you will render your "drawable"s, there are 2 options :
- you put all "drawable"s in a list (of drawable*) and the draw methods must be virtual.
- the draw methods are non-virtual and you have to use separate strong-typed lists (a list of model*, a list of particle_system*...).
This example is probably not relevant, but I hope you get the idea.
Be careful anyway, calling a virtual method has a tiny cost. It''s probably not a good thing to make a million virtual calls per frame.
SaM3d!, a cross-platform API for 3d based on SDL and OpenGL.The trouble is that things never get better, they just stay the same, only more so. -- (Terry Pratchett, Eric)
quote:Original post by rodzilla Only one rule : whenever you use virtual methods, the destructor must be virtual.
One question though: if you use virtual methods in your base class, those methods in your derived class are virtual whether or not you specify "virtual" explicitly. Why does this not also happen for destructors?
Of course, the destructor is a very special method, because when you call it (via delete or when exiting a block), all destructors in the class hierarchy will be invoked.
BTW, when redefining a virtual method (in a child class), you should use the "virtual" keyword. It doesn''t change anything as far as the compiler is concerned, but it make the code more readable.
SaM3d!, a cross-platform API for 3d based on SDL and OpenGL.The trouble is that things never get better, they just stay the same, only more so. -- (Terry Pratchett, Eric)
Sounds more like you are using inheritance when it''s not needed.
The simple way to do this is rather have apointer in the player class that points to the 3D object. This allows more freedom. The object has the routines for movement transformation and so on. The base position is handled by the player class. The offset positions are handled by the object. This way the person can change what object they are controlling and so on. Lets say your character what''s to drive a vehicle. all you have to do is swap the erase the previous boject and load a new one and give the pointer to the player class.
class point { float x,y,z; }
class Object3D { int number vertices; point *vert; /*and so on */ }
class player { int health; float x,y; Object3D *p; }
in herantance would be better used in something like building NPC VS chracters.
With the above methode I gave you manage the memory you need to call what ever destructors to get rid of the lower classes. Example: the points that are used would need to be called then the object. Make dynamic arrays to the sub classes rather than inherit them.
the other thing the It makes more sence to have a object as a sub set of a character rather than the other way around. The character may change objects the object wont change chracters. Even if the same type of object is used for many characters.
Delete your stuff in your base class destructor (or even keep that protected cleanup function, it''s handy if you want to reset your object without destroying it), and make your derived contructor completely empty (unless the derived class does extra memory allocation of its own).
