🚀 go-pugleaf

In article <3viclo$8cf@sunsystem5.informatik.tu-muenchen.de>,
Ulf Schuenemann <schuenem@informatik.tu-muenchen.de> wrote:
>
>I've posted Ajay Kamdar's proposal to the german DIN-group (most of them
>from Siemens Nixdorf Informationssysteme AG) at ISO.
>Manfred Lichtmannegger made a good point (new surprises) in his answer:
>

> 
> The main problem with the proposal is that if you remove the last virtual method,
> the destructor will loose its implicit virtual, independently whether the virtual
> was semantically necessary or not.
> 
> I think this side effect would really surprise programmers. Therefore the
> proposal would reduce the frequency of a common programming error by
> introducing a new subtlety. You reintroducing a new area for this common
> programming error, as it is hard ito trace whether the destructor has lost
> its virtuality by changes in direct or indirect base classes.
> 

A similar "problem" can be said to exist for the RTTI enhancements voted
into the CD. The result of a typeid expression is dependent upon whether
the expression references a polymorphic type or not. Type information for
the complete object is available via a base class pointer or reference
only if there exists atleast one virtual function. Remove the last virtual
function and a program using dynamic casts or typeid will behave
differently. This adds a level of subtlety to the language, and yet 
RTTI has been accepted in its current form.

Hence the change I have proposed does not add any new subtlety to the
language. The subtlety of a change in program behavior when the last
virtual function is removed already exists and programmers already need
to grapple with the issue. The decisions made for RTTI lay the precedence
for accepting the best possible solution without necessarily coming up
with the perfect answer for both polymorphic and non-polymorphic types.
In this sense, my proposal is very similar in spirit.  My proposal would
elminate a common source of programming error, but would not by itself
add a new source of programming error.

>      
> MfG Manfred Lichtmannegger


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