 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
sb
Guest
|
 Posted: Wed Feb 25, 2004 3:13 pm Post subject: deriving from STL containers |
 |
|
We had a discussion about this in c.l.c++ ("implicit constructor"
thread). I thought I'd ask here, since people seem to be, on average,
more intelligent here than over in the unmoderated group for some
reason.
When is it OK to derive from STL containers and when is it not OK? The
reasons should be specific to STL containers, and not concrete types
with all non-virtual methods in general.
For example, what is wrong with
struct named_vector : public vector<int> {
string name;
};
if I'm never going to let vector<int>* "own" named_vector ?
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
 |
tom_usenet
Guest
|
| Posted: Thu Feb 26, 2004 12:10 am Post subject: Re: deriving from STL containers |
|
|
On 25 Feb 2004 10:13:11 -0500, [email]spam_bait101 (AT) yahoo (DOT) com[/email] (sb) wrote:
| Quote: | We had a discussion about this in c.l.c++ ("implicit constructor"
thread). I thought I'd ask here, since people seem to be, on average,
more intelligent here than over in the unmoderated group for some
reason.
When is it OK to derive from STL containers and when is it not OK? The
reasons should be specific to STL containers, and not concrete types
with all non-virtual methods in general.
For example, what is wrong with
struct named_vector : public vector<int> {
string name;
};
if I'm never going to let vector<int>* "own" named_vector ?
|
There are two situations where you might want something like that:
1. A utility class used all over the place. In this case, there is a
danger than someone somewhere sometime will get confused and delete it
through a vector pointer. In this case it might be more appropriate to
use private inheritence and re-expose the interface with using
declarations.
2. A business logic class. In this case, it's unlikely that you want
the whole vector interface, and you probably need to intercept some of
the vector logic in any case due to other invariants, etc.
However, if you are encapsulating the named_vector (e.g. its a private
nested class), then I don't see much harm. Turning a vector<int> into
a named_vector can be a bit of a pain to do efficiently. e.g.
named_vector v;
v.name = "Tom";
v.swap(normalvector);
There is has been discussion in the standards committee about making
delegation and therefore the ideal implementation (via aggregation) a
bit easier to write by adding some language support for argument
forwarding, etc.
Tom
--
C++ FAQ: http://www.parashift.com/c++-faq-lite/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Dhruv Matani
Guest
|
| Posted: Thu Feb 26, 2004 12:20 am Post subject: Re: deriving from STL containers |
|
|
On Wed, 25 Feb 2004 10:13:11 -0500, sb wrote:
[I haven't read the discussion as yet, but I'm sure that this particular
point will have been mentioned by someone or the other].
| Quote: | For example, what is wrong with
struct named_vector : public vector<int> {
string name;
};
if I'm never going to let vector<int>* "own" named_vector ?
|
Consider this:
std::vector<int>* piv = new named_vector;
delete piv;
--
Regards,
-Dhruv.
Proud to be a Vegetarian.
http://www.vegetarianstarterkit.com/
http://www.vegkids.com/vegkids/index.html
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
