John Nagle <nagle@animats.com> wrote:

>    If this area of C++ is altered, it would be appropriate to
> prohibit overriding a non-virtual member function in a derived
> class.  That's almost always an error, and one that requires
> looking at two files far apart to detect.  I'd prohibit it
> entirely, but somebody will probably have some obscure use for
> it, so perhaps it should be possible to force it with some keyword.

Well, of course you know that you cannot override a non-virtual member
function in a derived class, you can only shadow (or hide) it.

On the one hand this is entirely appropriate for non-virtual private
member functions. Why should the private innards of a base class prevent
me from (re)using a member name in a derived class ?

But there even is an idiom that uses this language feature, which I
don't consider obscure at all. It builds on the 'instrumented interface'
pattern and can be used to achieve DBC-like functionality in C++:

First, to recap, the private interface pattern:
- virtual functions are always private or protected
- Instead of a public virtual function, use a public wrapper to call a
private (or protected if need be) virtual function.=20

Benefits:
This serves to decouple the public interface from the derived-class
interface. It also provides a place where instrumentation can be added
that applies to all implementations of the virtual function throughout
the hierarchy.

The way to implement DBC on top of this is obvious then: Instrument the
wrapper to check preconditions and postconditions.

One feature of DBC is that derived classes may support weaker
preconditions and stronger postconditions. C++ contains no native
support for this concept beyond covariant return types. Thus, if you
provide a derived class, you may need a different wrapper, that checks
the co-/contra- variant pre- and postconditions.=20

Here reusing the same name for the wrapper as is used in the base class
is entirely natural. It even is  required, if the classes should also be
usable in statically polymorphic contexts (templates).

In a way this is not much different from overloading: Overloading
provides for different function having the same name in one scope, name
shadowing provides for the same across an inheritance hierarchy. In both
cases it usually is wrong to use the same name for different
functionality, but it is correct to use the same name for different
variations of the same functionality. Thus allowing name hiding in a
class hierarchy is no more (or less) error-prone than allowing function
overloading. Used improperly both can create a nightmare for
understanding and maintenance. Used properly they can be a valuable tool
to improve understandability and maintainability.

C++ generally does not prevent you from shooting yourself in the foot.
We should not forbid a feature just because it can be misused by the
thoughtless.

Just my 2 euro-cent

Regards, J=F6rg


--=20
J=F6rg Barfurth                         joerg.barfurth@attglobal.net
<<<<<<<<<<<<< using std::disclaimer;  <<<<<<<<<<<<<<<<<<<<<<<<<<<<
Software Developer                    http://util.openoffice.org
StarOffice Configuration      =3D Jetzt erh=E4ltlich:StarOffice 6 Beta

---
[ 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.research.att.com/~austern/csc/faq.html                ]

> The current C++ Standard has three fundamental forms of inheritance:
> public, protected and private. Superficially each of these has an extra
> flavour of virtual. I say superficially because effectively any virtual
> base should be treated as if it is public. ...

   If this area of C++ is altered, it would be appropriate to
prohibit overriding a non-virtual member function in a derived
class.  That's almost always an error, and one that requires
looking at two files far apart to detect.  I'd prohibit it
entirely, but somebody will probably have some obscure use for
it, so perhaps it should be possible to force it with some keyword.

     John Nagle

---
[ 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.research.att.com/~austern/csc/faq.html                ]