Re: Deriving from concrete types
alan_mckenney1@yahoo.com (Alan McKenney) wrote (abridged):
However, just in the last hour, I find myself writing a class
which is publicly derived from std::vector .
The situation is that I have a class to implement a configuration
table. The (private) member object that holds the table data was
originally
typedef std::vector<Entry> KeywordData
std::vector<KeywordData> tableData;
That these are private does lessen the problem. It means the "public
inheritance" isn't really very public.
struct KeywordData { std::vector<Entry> data; std::string keyword; };
but since I wanted to preserve the interface, I found myself
writing forwarding functions for large parts of the std::vector
interface, with frequent trips to the std::vector man page to
get all the types just right.
It sounds like you tried to add all the documented vector functions. I
don't think you needed to do that - especially as the variables are
private, meaning there was no chance of breaking client code. You only
need to add the functions you needed.
In fact, one of the benefits of wrapping the vector is to see how the
interface you really need differs from what vector provides. I have known
cases where I found I didn't need begin/end and iterators, or where I
didn't need random access. "struct KeywordData" lets your object be
itself. At best this leads to new insights about the data.
Another way in which the class can grow is by moving more code into the
new class. For example, if begin/end is needed by print and nothing else,
then making print a member means you can remove begin/end from the public
interface. Again this gives more insights as to what the class is really
about. Strive for minimal interfaces.
and the "gotchas" are obvious, at least to anyone who reads
this newsgroup :-)
Do you think so? The code which implicitly converts your class into the
base class may be in one place, and the code that deletes the base class
may be in another, so that it is not obviously wrong even to an
experienced programmer. Although that's unlikely to happen here, it's an
insidious problem.
The other gotcha is that names from the base class get injected into the
derived scope's scope. In the worst case, the base class has code like:
protected:
virtual void print();
and the print function you add overrides the one in the base class and so
gets called unexpectedly. Your current library vendor may not do anything
like that, but who knows what future ones will do? It's even possible that
the next C++ standard will add member functions to std::vector.
Is this gotcha obvious? Has it been mentioned in the thread before?
Inheritance is a tightly-coupled relationship, best avoided except when it
is needed.
-- Dave Harris, Nottingham, UK.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]