Re: deriving a class with a subset of base class methods?
eckhardt@satorlaser.com (Ulrich Eckhardt) wrote (abridged):
[private derivation versus aggregation]
So, I can't imagine any change to the underlying container that
would require client code to be changed in one case but not
the other.
In the inheritance case, any client-defined derived classes will find
functions that are virtual in the private base (ie std::list<int>) are
also virtual in their client class, and liable to be called by the
private base class, even if they are declared private by the client.
Which is bad.
Also, any names in the private base class will be visible to the derived
client class, even though they cannot be used. This can create
ambiguities.
If the private base class adds a new function with a name that matches a
using-declaration in the intermediate class, it will become visible to
client code even if that doesn't inherit. This is already an issue if you
just want the const version of begin() and not the non-const version. It
may be an issue with future versions of the standard, eg if std::list<>
::begin() gets an overload that takes an allocator or something.
You are relying on the author of the private base class to be
conservative in what they change. Admittedly that is a fairly safe bet
when the author is the standards committee, but it is still a gamble and
illustrates that you have a more tightly-coupled interface than
aggregation.
I used to do it. I don't any more. I have no doubt that it's technically
the wrong thing to do.
-- Dave Harris, Nottingham, UK.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]