This thread reminds me this article :
Conversations: Virtually Yours

----
David Sporn AKA Sporniket

Sabreman it is not neccassary to have a virtual dtor for the base class even if you are deleting a derived instance via pointer.

The virtual dtor just makes sure the correct dtor is called. If the derived class uses another function to clean up such as Create() and Destroy() and the derived dtor is empty { } then there is no need to make the base class virtual.

As long as all derived classes define there dtor's as empty then the base class can be virtual.

The correct answer to "What is wrong with making the base classes dtor not virtual" is that there may be a time a user of the class will try to derive there own class from the base class and not knowing the the base classes dtor is not virtual they may put code in there derived class' dtor and it will not be called correctly.


[edited by - ph33r on January 22, 2003 1:06:28 AM]

quote: Original post by ph33r
Sabreman it is not neccassary to have a virtual dtor for the base class even if you are deleting a derived instance via pointer.

The virtual dtor just makes sure the correct dtor is called. If the derived class uses another function to clean up such as Create() and Destroy() and the derived dtor is empty { } then there is no need to make the base class virtual.

As long as all derived classes define there dtor''s as empty then the base class can be virtual.

The correct answer to "What is wrong with making the base classes dtor not virtual" is that there may be a time a user of the class will try to derive there own class from the base class and not knowing the the base classes dtor is not virtual they may put code in there derived class'' dtor and it will not be called correctly.

No. The C++ standard says that the behaviour for non-virtual base class dtors is undefined. That means ANYTHING could happen when the object is destroyed, from do absolutely nothing to crashing your computer. Good programmers avoid invoking undefined behaviour.

If a base class has a dtor that is not virtual when you call delete it will call the bases dtor only. The derived dtor''s will not be called because the derived classes are of type pointer to the base. That is pretty much defined behavior to me.

error 500x2

ph33r - nope. Your compiler might handle it that way, but you should not rely on it - reformating your hard drive or running nethack (some older versions of gcc were known to insert code launching hack when encountering some undefined behavior cases ) are also valid results.

quote: ISO C++ Standard - 5.3.5-3
"In the first alternative (delete object), if the static type of the operand is different from its dynamic type, the static type shall be a base class of the operand's dynamic type and the static type shall have a virtual destructor or the behavior is undefined. In the second alternative (delete array) if the dynamic type of the object to be deleted differs from its static type, the behavior is undefined."

a) if you call delete on a Foo* which points to a Bar, then Foo must be a base class of Bar and must have a virtual destructor.

b) you can only call delete[] on a Foo* if it exactly points to a bunch of Foos and nothing else.

[ Start Here ! | How To Ask Smart Questions | Recommended C++ Books | C++ FAQ Lite | Function Ptrs | CppTips Archive ]
[ Header Files | File Format Docs | LNK2001 | C++ STL Doc | STLPort | Free C++ IDE | Boost C++ Lib | MSVC6 Lib Fixes ]

[edited by - Fruny on January 22, 2003 2:00:13 AM]

quote: Original post by ph33r
If a base class has a dtor that is not virtual when you call delete it will call the bases dtor only. The derived dtor''s will not be called because the derived classes are of type pointer to the base. That is pretty much defined behavior to me.

And where in the standard does it say that?

3 people now disagree with you. Better give in before that increases

sark,
your right the standard obviously does say that and I was confused because compilers implement it in a defined way.

Regardless if I'm wrong or not giving in because others "say so" is not thinking for yourself rather it's blindly following sheep.

[edited by - ph33r on January 22, 2003 2:51:40 AM]

quote: Original post by ph33r
Regardless if I'm wrong or not giving in because others "say so" is not thinking for yourself rather it's blindly following sheep.

Maybe so, but this is discussing fact, not opinion. With issues like this, people are either right or wrong. You cant "think for yourself" when you are dealing with fact - the only way to win the argument is to refer to reliable sources (the C++ standard in this case). At any rate, I was wrong to implicate that the side with the more people on are necessarily correct.

[edited by - sark on January 22, 2003 3:02:31 AM]

well actually sark the same principle applies when discussing opinions. also scientists "think for themselves" plenty of times. just look at the debate about the "speed of gravity" debate going on right now.

quote: Original post by ph33r
Regardless if I'm wrong or not giving in because others "say so" is not thinking for yourself rather it's blindly following sheep.

Thinking for yourself does not involve rejecting what other people say out of hand. It involves considering what other people say and, if you feel a claim should be rejected, coming up with reasoning for why it should be rejected. In your case, to rebut a claim made on the basis of what the C++ Standard states, your recourse should be to the C++ Standard. Rejecting the C++ Standard because of what your compiler does is not thinking for yourself, it is taking your compiler's results at face-value. If you do not know what the C++ Standard says on the matter, you cannot rebut it, and have no grounds on which to tell others they are wrong in their interpretation of the Standard.

[edited by - SabreMan on January 22, 2003 6:00:18 AM]