Pete Becker is right, but C++ really should prevent
overriding of a non-virtual method.  That's almost always
an error, and it's hard to find, because it's a non-local error,
where two things far apart textually are inconsistent.
Those are the kinds of errors you want the compiler to
catch if at all possible.

     I'd just prohibit it.  No new syntax; just make it
an error to override a non-virtual method.  The very
rare occasions in which it is useful don't justify the
large number of errors that occur when it's wrong.

     John Nagle
     Animats

Pete Becker wrote:


> I misunderstood your example. Replace 'MUST_OVERRIDE' with '= 0'. It's
> already in the language.

---
[ 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                       ]

In article <3CE9BF28.7090809@animats.com>, John Nagle
<nagle@animats.com> writes
>    I'd just prohibit it.  No new syntax; just make it
>an error to override a non-virtual method.  The very
>rare occasions in which it is useful don't justify the
>large number of errors that occur when it's wrong.

I think that is a complete non-starter. However much many of us abhor
the use of derivation to tweak a type, it is often done and in good
hands it does not cause errors.

--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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                       ]

John Nagle <nagle@animats.com> writes:

|>       Pete Becker is right, but C++ really should prevent
|>  overriding of a non-virtual method.  That's almost always an
|>  error, and it's hard to find, because it's a non-local error,
|>  where two things far apart textually are inconsistent.  Those are
|>  the kinds of errors you want the compiler to catch if at all
|>  possible.

|>       I'd just prohibit it.  No new syntax; just make it an error
|>  to override a non-virtual method.  The very rare occasions in
|>  which it is useful don't justify the large number of errors that
|>  occur when it's wrong.

My experience is just the opposite.  I've not often overriden a
non-virtual function, but when I have, I did so without knowing it,
and I wanted the results I got.

Normally, I would argue that the author of the derived class should
not even know the names of private functions other than the ones he
should override.  (This is, in fact, one of the arguments against
private virtual functions -- the author of the derived class should
not have to even look at the private section of the class definition.)
Given this, what is to prevent name clashes, if name clashes are made
illegal?

--=20
James Kanze                                mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                    Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)179 2607481

---
[ 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                       ]