Re: Future of C++
Andre Kaufmann wrote:
Andrei Alexandrescu wrote:
Razvan Cojocaru wrote:
Every base class that _has_at_least_one_virtual_member_function_ should
[...]
While I agree that this rule applies to most cases, I'll point out that
exception classes do have virtual functions but don't need a virtual
destructor.
What if the exception
class Exception : ExceptionBase {....};
is thrown by:
throw new Exception();
?
{ Even if it's a rare case or "don't write it this way code" - but
anyways it's just the same as needing non virtual destructors in base
classes with virtual functions -> rare case IMHO too).
That's more than just a rare case, it's a faux pas of the dimension of a
presidential candidate's extramarital affair. catch (...) will be unable
to do proper teardown of the exception object and that's a net leak of
state. Before anyone points out that MFC does exactly that, I should
note that I have a marksman badge and a short temper :o).
Also ScopeGuard's implementation uses a base class with no
virtual destructor.
Aren't stack allocated objects which use virtual functions a minority ?
I don't know for sure.
They are, and probably few if any would shed a tear if they were
disallowed entirely. In fact it would rid us of a number of problems
starting with slicing.
A virtual destructor introduces somewhat overhead, but in the context of
polymorphisms it's IMHO needed, if the objects are allocated on the
heap. For all the other ones (rare cases) the overhead is IMHO
neglectable or can be omitted by declaring the destructor explicitly non
virtual e.g. a solution would be to use the explicit keyword:
explicit ~myclass() {} // Explicitly non virtual destructor
Currently the compiler warns me about a "non virtual destructor", when I
add virtual functions. But to prevent this warning I have to temporarily
disable it - which I can't if I want to support all C++ compilers. Or by
adding a virtual destructor ?!
So in any case it would make sense to enhance the C++ language, to allow
me to express my intention, to have explicitly a "non virtual destructor".
To sum it up we have the choice between:
a) To pay for the rare cases where the destructor is made automatically
virtual, where it shouldn't be and where the developer has forgotten
to add a keyword to make the destructor explicitly non virtual.
b) Current state: Destructor stays non virtual, but when polymorphism
is used with heap objects memory leaks and weird behavior at
runtime may occur.
I would decide a)
Makes sense to me too. But it's just not going to happen.
Andrei
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]