Re: Non-virtual destructors & valarray memory allocation
Steve Clamage wrote:
Michael Hopkins wrote:
1) Why were the std:: library containers not given virtual
destructors - is this a feature or an oversight? If the
latter, I wonder if it would be something that could be
changed easily in the upcoming standard without breaking
current code.
The containers were deliberately designed not to support
run-time polymorphism. They are intended NOT to be derived
from. The reason is to support efficient implementation based
on compile-time polymorphism.
One doesn't necessarily exclude the other; Barton and Nackman
have shown how to support run-time polymorphism AND be very
efficient (as efficient as the STL, at any rate) in cases where
the actual type is know.
You can use a container type as a member of class that has
different or additional features.
We would like to derive publicly from them in a couple of
cases and now have to be more disciplined than we should
need to be about how we use those types.
Deriving from non-polymorphic classes is a Bad Idea.
Do you mean non-polymorphic classes like std::iterator<>, or
std::unary_function? :-)
The problem is, I think, that the C++ language feature of
derivation can be used for several different design features --
OO inheritance is just one. When the C++ language feature is
used to implement OO inheritance, then the base class must have
a virtual destructor; in fact, the base class must be designed
to support this use. But when the language feature is used for
other reasons, other rules apply. While it might be marginally
safer if std::unary_function had a protected destructor, I don't
find this to be a problem in real code -- programmers just don't
have std::unary_function*, period, much less delete them. And
of course, if std::unary_function did have a protected
destructor, then classes derived from it could never be members
of a union. (I think that Francis has a proposal under
consideration for explicitly declaring that we want the default
semantics. Maybe this could be used to declare a protected
destructor without the destructor becoming non-trivial.)
Having said all this, I'm still very sceptical about deriving
from std::vector. It wasn't designed to be used as an OO base
class -- that's for sure. But I don't think it was designed to
be used as some other type of base class, either.
--
James Kanze GABI Software
Conseils en informatique orient9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S9mard, 78210 St.-Cyr-l'cole, France, +33 (0)1 30 23 00 34
---
[ 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.comeaucomputing.com/csc/faq.html ]