By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,341 Members | 1,395 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,341 IT Pros & Developers. It's quick & easy.

Deriving from a STL container

P: n/a
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 ?
Oct 30 '07 #1
Share this Question
Share on Google+
17 Replies


P: n/a
On Oct 30, 12:50 pm, mosfet <john....@anonymous.orgwrote:
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. Also any extension to a std container may
not guarantee compatability with the std algorithms, you clients would
need to be aware of this.

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.

Oct 30 '07 #2

P: n/a
bjeremy wrote:
On Oct 30, 12:50 pm, mosfet <john....@anonymous.orgwrote:
>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.
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.
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.

In any case, there are issues that need to be considered, but there is
no hard rule saying "do not inherit".

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

P: n/a
On Oct 30, 1:38 pm, "Victor Bazarov" <v.Abaza...@comAcast.netwrote:
bjeremy wrote:
On Oct 30, 12:50 pm, mosfet <john....@anonymous.orgwrote:
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.
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?
>
In any case, there are issues that need to be considered, but there is
no hard rule saying "do not inherit".

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

Oct 30 '07 #4

P: n/a

mosfet wrote in message...
Could someone tell me why it's considered as bad practice to inherit
from STL container ?
They do not have virtual destructors.
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 ?
You can derive from the standard containers, but you need to be aware of the
restrictions on using the derived classes.
[ mainly, do *not* handle it through a base pointer.]

--
Bob R
POVrookie
Oct 30 '07 #5

P: n/a
BobR wrote:
mosfet wrote in message...
>Could someone tell me why it's considered as bad practice to inherit
from STL container ?

They do not have virtual destructors.
By answering this question you essentially confirm that "to inherit
from STL container" is "bad practice". Correct? Or is that more of
"those who say it's bad practice give absence of virtual destructors
as the rationale" type of answer?
>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 ?

You can derive from the standard containers, but you need to be aware
of the restrictions on using the derived classes.
[ mainly, do *not* handle it through a base pointer.]
So, should the OP take it that it's really not such bad practice, after
all, to derive? <g>

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

P: n/a
On 2007-10-30 20:01, bjeremy wrote:
On Oct 30, 1:38 pm, "Victor Bazarov" <v.Abaza...@comAcast.netwrote:
>bjeremy wrote:
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?
It is rather more like using private inheritance to achieve composition
than an alternative to.

--
Erik Wikström
Oct 30 '07 #7

P: n/a
On Oct 30, 2:26 pm, Erik Wikström <Erik-wikst...@telia.comwrote:
On 2007-10-30 20:01, bjeremy wrote:
On Oct 30, 1:38 pm, "Victor Bazarov" <v.Abaza...@comAcast.netwrote:
bjeremy wrote:
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?

It is rather more like using private inheritance to achieve composition
than an alternative to.

--
Erik Wikström
Yeah.. I know what Victor was saying... The point I was trying to make
is that a lot people (Sutter, Myers, etc) suggest that if you do not
intend to override virtual members then in that scenario they *prefer*
composition to private inheritance. Since std containers contain no
virtual functions to override, then there would be no reason the
prefer private inheritance over composition... Actually, I'm not
married to this issue, just Victor's flippant response reminded me of
grade school... so I thought I would get in on the act.

Oct 30 '07 #8

P: n/a
BobR wrote:
>
mosfet wrote in message...
>Could someone tell me why it's considered as bad practice to inherit
from STL container ?

They do not have virtual destructors.
That's an orthogonal issue. The template classes std::iterator<or
std::unary_function<also do not have virtual destructors, yet they are
clearly provided to be inherited from.
Best

Kai-Uwe Bux

Oct 30 '07 #9

P: n/a
On Oct 30, 2:48 pm, Kai-Uwe Bux <jkherci...@gmx.netwrote:
However, pointers to std::some_container< some_type are not really likely
to be used polymorphically.
Good point.
..
..
..
The standard algorithms work on ranges specified by pairs of iterators. They
will work just fine with iterators obtained from containers derived from
std::vector. (Actually, that is part of the problem and not part of a
solution, see below).
Wouldn't this depend on how exaclty how you extend the container. The
for example iterators would assume they are iterating over a
std::vector, not your derived vector.
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.

That actually amounts to writing tons of code (just count the number of
methods in std::vector and you get an idea of how many stupid forwarding
methods you will have to provide to extend container classes this way). You
can cut down on that considerably by using private inheritance.
Right.. but a drawback might be that you need to take care not
override std containers members. I guess this is still a problem
whether inheritance or composition is used, however it is clearer if
the future developer sees a "virtual" member specifically.
Also, what if another developer wants to inherit from your derived
container class?

Anyway... Herb Sutter had a good article about this in his GotW
series: http://www.gotw.ca/publications/mill06.htm
Oct 30 '07 #10

P: n/a
On 2007-10-30 15:17:42 -0400, "BobR" <re***********@worldnet.att.netsaid:
>
You can derive from the standard containers, but you need to be aware of the
restrictions on using the derived classes.
[ mainly, do *not* handle it through a base pointer.]
Mainly, do *not* delete it through a base pointer.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

Oct 30 '07 #11

P: n/a
On 30 Oct, 19:42, bjeremy <bjer...@sbcglobal.netwrote:
Yeah.. I know what Victor was saying... The point I was trying to make
is that a lot people (Sutter, Myers, etc) suggest that if you do not
intend to override virtual members then in that scenario they *prefer*
composition to private inheritance. Since std containers contain no
virtual functions to override, then there would be no reason the
prefer private inheritance over composition...
This makes no sense to me - there is an excellent reason to
prefer private inheritance over delegation in this case
(which is what I believe you mean by "composition", since
as has been pointed out private inheritance also implements
composition) - it's much less code, and much less error-prone.

Oct 30 '07 #12

P: n/a

Victor Bazarov wrote in message...
BobR wrote:
mosfet wrote in message...
Could someone tell me why it's considered as bad practice to inherit
from STL container ?
They do not have virtual destructors.

By answering this question you essentially confirm that "to inherit
from STL container" is "bad practice". Correct?
Not correct! I don't think it's "bad practice". The "bad practice" might
come into play in how you use the Derived_From_Container class.
"Slicing" is not bad, unless it's un-intentional. Sometimes it can help you,
sometimes it will kill you. Knowing "when" is the important part.
"Memory leaks" are bad, IMHO.
Or is that more of
"those who say it's bad practice give absence of virtual destructors
as the rationale" type of answer?
Yeah, more along that line of thinking.
As long as you are aware of the lack of virtual destructors, there are times
when inheriting from a std container can[1] be used in place of a more
complex design.
I've only inherited from std::vector for a special task in a personal
program. I don't think I'd use it in a serious program. I don't try to
'shoehorn' code in. Use the proper tool for the job at hand.

[1] - Just because you can, doesn't always mean you should. <G>
>
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 ?
You can derive from the standard containers, but you need to be aware
of the restrictions on using the derived classes.
[ mainly, do *not* handle it through a base pointer.]

So, should the OP take it that it's really not such bad practice, after
all, to derive? <g>
The OP should study what virtual destructors do, the class (s)he plans to
inherit from, and then make a decision.
Or even better, describe exactly the problem, and let you experts guide the
way.

--
Bob R
POVrookie
Oct 30 '07 #13

P: n/a

Kai-Uwe Bux wrote in message...
BobR wrote:

mosfet wrote in message...
Could someone tell me why it's considered as bad practice to inherit
from STL container ?
They do not have virtual destructors.

That's an orthogonal issue. The template classes std::iterator<or
std::unary_function<also do not have virtual destructors, yet they are
clearly provided to be inherited from.
I didn't say "don't inherit", I said 'virtual destructors' are why some
people *say* it's bad practice (what the OP asked, AFAIK.).
<G>
I have some classes inherited from std::vector that works smooth as glass.
[ and the class has a // comment about further inheritance, and destruction
through a base pointer (thanks Pete.).]

--
Bob R
POVrookie
Oct 31 '07 #14

P: n/a
mosfet <jo******@anonymous.orgwrote:
Could someone tell me why it's considered as bad practice to inherit
from STL container ?
Because there is nothing that can be gained from doing it.
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 ?
Not at all. You just need to write your custom functions. If you follow
the same idiom as the standard algorithms, your functionality will be
useful for several containers.
Oct 31 '07 #15

P: n/a
On Oct 30, 8:59 pm, Kai-Uwe Bux <jkherci...@gmx.netwrote:
BobR wrote:
mosfet wrote in message...
Could someone tell me why it's considered as bad practice to inherit
from STL container ?
They do not have virtual destructors.
That's an orthogonal issue. The template classes
std::iterator<or std::unary_function<also do not have
virtual destructors, yet they are clearly provided to be
inherited from.
Yes, but they were designed to be base classes, std::vector
wasn't. In this case, I think the difference is that classes
like std::iterator<don't have any semantics; you'd never,
never have an std::iterator<>* in your program, much less delete
through it. This is a lot less true for std::vector<>*.

My own feeling is that std::vector<isn't designed for use as a
base class, and so shouldn't usually be used as a base class.
On the other hand, if the use were local and well controled, I
don't think I'd get up in arms about it. I would object to it
if the derived class were some general and widely used
component, however.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Oct 31 '07 #16

P: n/a
On Oct 30, 5:15 pm, tragomaskhalos <dave.du.verg...@logicacmg.com>
wrote:
On 30 Oct, 19:42, bjeremy <bjer...@sbcglobal.netwrote:
Yeah.. I know what Victor was saying... The point I was trying to make
is that a lot people (Sutter, Myers, etc) suggest that if you do not
intend to override virtual members then in that scenario they *prefer*
composition to private inheritance. Since std containers contain no
virtual functions to override, then there would be no reason the
prefer private inheritance over composition...

This makes no sense to me - there is an excellent reason to
prefer private inheritance over delegation in this case
(which is what I believe you mean by "composition", since
as has been pointed out private inheritance also implements
composition) - it's much less code, and much less error-prone.
I'm not intending to make a snyde comment so I apologize if it comes
across that way, but it seems to me that you are arguing for increased
coupling between objects for the sake of saving yourself some key-
strokes. For me, I try and always use the weakest relationship between
objects that I can get away with, not saying this is "the way" just
that is what I try to do.. Since in this example we know that the std
container will not have a) and protected data that I need to use, and
b) the std container contains no virtual functions I need to override
then I will use containment, forwarding functions have never been a
chore to write or get right. If you choose to inherit in this case, it
appears that you would be creating a needless dependency.

Oct 31 '07 #17

P: n/a
On 31 Oct, 15:28, bjeremy <bjer...@sbcglobal.netwrote:
On Oct 30, 5:15 pm, tragomaskhalos <dave.du.verg...@logicacmg.com>
wrote:
This makes no sense to me - there is an excellent reason to
prefer private inheritance over delegation in this case
(which is what I believe you mean by "composition", since
as has been pointed out private inheritance also implements
composition) - it's much less code, and much less error-prone.

I'm not intending to make a snyde comment so I apologize if it comes
across that way, but it seems to me that you are arguing for increased
coupling between objects for the sake of saving yourself some key-
strokes. For me, I try and always use the weakest relationship between
objects that I can get away with, not saying this is "the way" just
that is what I try to do.. Since in this example we know that the std
container will not have a) and protected data that I need to use, and
b) the std container contains no virtual functions I need to override
then I will use containment, forwarding functions have never been a
chore to write or get right. If you choose to inherit in this case, it
appears that you would be creating a needless dependency.
Your desire for the weakest relationships is exactly correct I
think, but if you contain a vector and delegate to it, and I inherit
privately from vector and make its operations available via
"using", it seems to me we are *both* tightly coupled to the vector.

However it turns out that Sutter (Exceptional C++ item 15) agrees
with you, and recommends using private inheritance "only when
absolutely necessary". So I'm not going to argue the point, but
I need to digest his and your arguments before I can convince
myself!

Oct 31 '07 #18

This discussion thread is closed

Replies have been disabled for this discussion.