With the namespace features, the "using" keyword allows member functions
from the base class to be exported explicitly.  How about a "unused"
keyword to explicitly deny member functions from being exported?

This would be useful in the case of, say an ellipse base class, with a
circle as a subclass and you wanted to allow all the ellipse operations
except for the scale_xy() member function.  Unless I miss my guess, the
only way to do this currently is to inherit ellipse privately or by
protected inheritance and explicitly export all but the scale_xy()
function in circle.

Either that, or have some sort of operator that says "I am exported in
this class only, but not in any derived classes, unless a 'using'
keyword is used".  Or even better, have both.

There are ways around it, such as causing scale_xy() to throw an
exception in the circle class, but it's not really in the spirit of
surpressing member functions in derived classes.

I am not aware of any such feature currently in the standard, but then I
haven't read it that closely, so I may have missed it.  Please enlighten
me if this is the case.

Alex Bache.
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article 74EAABD5@sil.com, Alex Bache <bache@sil.com> writes:
>With the namespace features, the "using" keyword allows member functions
>from the base class to be exported explicitly.

No, that isn't correct. Class members are implicitly exported according
to their accessibility.

The "using" keyword allows base-class members to be *imported* into
the current class scope, usually for overloading purposes.

>  How about a "unused"
>keyword to explicitly deny member functions from being exported?

We already have a keyword for that purpose. It is spelled "private".

>This would be useful in the case of, say an ellipse base class, with a
>circle as a subclass and you wanted to allow all the ellipse operations
>except for the scale_xy() member function.

It is far from clear that this approach consitutes good design.
Often it makes more sense to add features to a derived class than
to remove features from base-class functionality. In C++, public
inheritance is assumed to model the IS-A relationship. If that
relationship does not apply, public inheritance is not appropriate.

In geometry, a circle is a special case of an ellipse. That does not
mean that a Circle class should be publicly derived from an Ellipse
class, particularly if the Ellipse class interface supports XY
scaling. That feature breaks the IS-A relationship. An alternative is
to derive both Circle and XYscalableEllipse from Ellipse, for example.

---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]