Re: Deriving from a STL container
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