Victor Bazarov wrote:
Nindi wrote:
Kai-Uwe Bux wrote:
Victor Bazarov wrote:
Kai-Uwe Bux wrote:
Nind...@yahoo.co.uk wrote:
Moreover are STL containers destructors virtual >
No. That means you should not use pointers to STL containers
polymorphically.
I think you wanted to say "you should not *delete* pointers to your
classes through pointers to STL containers from which your classes
derive".
Yes, thanks.
Standard containers don't have virtual functions (AFAICR),
so using them polimorphically is kind of impossible.
I was using the phrase "to use polymorphically" more loosely. To me,
the very fact that a B* may have a different dynamic type qualifies
as polymorphic use. I don't know whether there is some standard
terminology that settles this language issue. However, the wording
you proposed is definitely less ambiguous.
Actualy I have been thinking about this. I don't think its a ver bad
idea inheriting from STL containers.
The statement above goes out of tune with what you say after it.
Firstly they don't have virtual
destructors, so it is very unlikely they were designed to be base
classes. Not having virtual destuctors makes them very error prone.
Secondly isn't ( when we have a choice) composition better than
inheritence since it is a weaker dependency so then doesn't that
naturaly lead to some sort of pmpl or bridge pattern instead ? Why
not use a pmpl or bridge ? well because there is alot more typing
involved, but this is a price I am willing to pay.
I also think its very easy to overlook the lack of virtual destructor
and use the derived class a template parameter to a smart pointer, not
good. I think I will avoid inheriting from STL containers.
Motorcycles do not have safety belts. Nor do they (at least those that
I know of) have airbags. Yet people ride them and enjoy all the nice
things one can enjoy while riding on a motorcycle (compared to cars or
trucks or buses).
Absence of a virtual destructor is NOT a valid reason not to derive
from a class IMO. It is usually just an excuse. You can quote me on
that.
Absence of virtual functions (d-tors or otherwise) means the class is
not intended to be used polymorphically. Polymoprhic use cannot go
without deriving. Deriving, however, can very simply survive and be
successfully used without polymorphic use.
If you're afraid to make a mistake, by all means, don't inherit from
standard containers (or any other classes).
Firstly I would like toapologies for a typo, it should have been
'I DO think its a very bad idea inheriting from STL containers.'
Secondly if there is a more safer and cleaner alternative then I think
by definition its better.
Thirdly, if I am driving a car around town and I choose NOT to wear a
seat belt simply because I always drive below the speed limit with the
utmost due care, it does not eliminate the possibility of a fatal
outcome from the actions of the people I share the road with. Here, as
in the case of deriving from STL containers I have a choice, to wear a
seat belt, or use composition. When I ride a motorbike, I have no such
a choice, so I make do with those restrictions. On the othe hand I
choose to wear a helmet.
I would like to see an example when I should derive from an STL
container and should NOT use composition instead.
'.. provides no virtual functions (other than the destructor which
we'll get to in a minute). This means it is not intended to be used
polymorphically, which is a strong hint against public inheritence.'
Exceptional C++, p82
Sutter
Yes he says PUBLIC inheritence, so maybe there is a case for non-public
inheritence. I think not, these are also mercilessly slaughtered in the
book except in a few special cases, which I am sure do not apply here.
N
