🚀 go-pugleaf

In article <3ver7t$61k@f111.iassf.easams.com.au>,
Rohan LENARD <rjl@f111.iassf.easams.com.au> wrote:
>In article <3v0pam$1lv@jabba.lehman.com>, Ajay Kamdar <ajay@lehman.com> wrote:
>>
>>Make the destructor of a class implicitly virtual if the class has any other
>>virtual functions.
>>
>
>Nice idea, but it really is a quality of compiler implementation issue.
>
>The compiler I use for everyday work gives me quality for code which
>has the problem you describe -
>bug.cc:9: warning: `class Bar' has virtual functions but non-virtual destructor

Yes, as things stand today, this is a quality of compiler implementation
issue. But is there a good reason for it to remain a quality of
implementation issue?

At one point in time in the history of C++, the virtual specifier was
required in the declaration of an overriding function in a derived class
even when the base class function being overridden was already declared
virtual. It could have been left as a quality of implementation issue for
the compiler to warn about a missing virtual specifier in an overriding
function. However, it was considered useful enough to enhance the language to
make the virtual specifier redundant in this case, and to specify the correct
behavior independent of which compiler was being used.

The situation I am addressing is quite analogous. If a class already has other
virtual functions, I know of no reason why anyone would want the destructor
to be non-virtual. There is only one correct thing to do here, and that is
to make the destructor virtual. So why should the language still insist
upon an explicit virtual specifier for the dtor and leave the behavior of
deleting an object of such a class via a pointer to its base class undefined
if the programmer forgets the virtual specifier? The cost of such a mistake
is often high, as many of us can vouch from personal experience.

One of the purposes of enhancements to a language is to make the language
easier to use. The enhancement I have proposed adds substantial value,
does not make the language bigger, makes the language more intuitive and
easier to use, is trivial to implement, requires only a minor modification
to the text of the DWP, has zero impact on object layout, has no unexpected
side effects which break existing programs, has precedence of enhancements
similar in spirit, and does not go against the grain of the design decisions
made for C++ so far.

Often there are good reasons for leaving some things as a quality of
implementation issue. However, I have yet to hear such a good reason for
maintaining status quo in the situation my proposal is addressing.


>There are many things like this in C++.  Should we mandate that the compiler
>complains if you don't have a destructor defined at all in a class with a
>virtual function ?  Or if you don't define a copy constructor when your
>class manages an object through a pointer ? ...

Unlike the case I am addressing, none of these examples have one obvious
right answer. My proposal is limited to suggesting what is obviously
the only right thing to do.


Regards,

- Ajay

-- 
Ajay Kamdar        |    Email: ajay@lehman.com    |    Standard Disclaimer 
Lehman Brothers    |    Phone: (201) 524-5048     |