C++Talk.NET

Kurt Bigler · Guest

Actually this warning is more general than that, but my primary motivation
for suggesting it is that I'd like to see the hole plugged that allows a
delete without the usually desired destructor calls occurring. In short...

I'd like to see a warning when a class makes a function virtual that
was not virtual in one of its base class. For destructors I'd like this to
include the case when a base class has no explicit destructor.

I'm suggesting that such a warning be made a requirement of the standard.

Someone I talked to thought that this idea had been brought up before, but
that it seems to have been lost.

Alternatively I'd like to see an empty virtual destructor generated by the
compiler if no destructor is present, whenever there are other virtual
functions in the class, and therefore an unsolicited vtable would not
result. I was forewarned that such an idea would not be received favorably
here, which is why I suggested the warning instead. The warning does also
cover much more ground.

There is another conceivable approach to aid in reliable destructor usage.
It leaves more responsibility with the programmer but also probably has
broader utiity. Correct me if I'm wrong I believe there is currently no way
for a class to specify (directly or indirectly) simply that it can not be
derived from. It strikes me that a mechanism for achieving this would be
useful in many situations, since there are various coding practices that are
safe in a leaf class that are not safe elsewhere, including defining a
non-virtual destructor in a simple class currently intended not to have a
vtable and not intended to be derived from.

Thanks,
Kurt Bigler

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]

Steve Clamage · Guest

Kurt Bigler wrote:

John Nagle · Guest

Arguably, overriding a non-virtual function should be
an error. But there's some obscure situation in which this feature
is useful, although few remember what it is. Someone may have
used that feature deliberately at some time in the past, so it
can't be fixed.

If something is an error 99+% of the time, and useful
<1% of the time, policy seems to be that it should not be
prohibited.

John Nagle
Animats

Steve Clamage wrote:

Joe Gottman · Guest

"John Nagle" <nagle (AT) animats (DOT) com> wrote