Re: Deriving from concrete types
RenjithMohan wrote:
<original post deleted>
This has been discussed umpteen times in this and other newsgroups.
I will summarize the points
1)Generally speaking the STL containers are not intended to be used as
base classes.
It is evident from the fact that they dont have a virtual destructor.
And you know what happens when you delete a base pointer if the
... object is a derived one. It is Undefined Behaviour.
If you provide such a class nothing prevents from your clients to do
so.
Except the same thing that prevents your clients from dereferencing
a null or deleted pointer: your clients' desire not to have their
programs crash.
To what extent should we use a convoluted solution instead
of an elegant solution just because a stupid user can use
it to make his program crash?
2)They dont have any protected members or virtual functions to warrant
the design of public inheritance.
If you need to provide enhanced functionality it is prefered to provide
non member functions to achieve this, much like the algorithms
This particular bit of dogma, like much of the
catechism of the C++ One True Way that gets
trotted out at every opportunity, depends upon some
assumptions about how C++ code will be used.
This bit of dogma assumes:
1. All C++ classes are created by all-knowing library
writers, who know best how the class may and
may not be used, while C++ classes are used
by clueless idiots who don't read documentation
and will start WWIII if we're not careful.
Now I grant you, this applies in a lot of cases
(which are well-represented in this newsgroup), but
in my experience, there are a lot of cases where
the user of the classes may know more than the
implementer, and where the ability to use a class
in ways that the author never intended is precisely
what makes the class useful.
2. The only reason for derivation is to allow
polymorphic use (treating a derived
class as a base class.)
If you need an object which acts just like a
std::vector, but you need a little extra functionality,
then deriving from std::vector is the *obvious* thing
to do.
That way, you get all the std::vector behavior "for
free", and you only need to add the extra member
function or two to get the desired extra
functionality.
Note that I didn't say: I'm working with a bunch
of vectors, but I want one of my vectors to act a little
different from std::vector. Instead, I need a Whatsit,
and what I need Whatsits to do turns out to be pretty
much what a std::vector does, plus some stuff.
So we're not talking about polymorphic use, and
there's no reason to pass around with pointers
to std::vector , unless you're entering an obfuscated
C++ contest.
On another note: some posters have indicated that
one should use "private" inheritance.
Now, I've never used private inheritance, but it
seems to me that if you derive privately from std::vector,
then all the std::vector functions are inaccessible
to the user of the class, which sort of defeats the
purpose.
Free functions are doable, but then you have
issues of possible name clashes, and you can't
use the member function syntax.
-- Alan McKenney
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]