Deriving from STL container
Fred Ma
Someone responded on an earlier thread that it isn't
normal to derive a user-defined container class from
the STL vector class. This was confirmed by the fact
that the vector class has no virtual destructor.
Just wanted to check this for sure. Reason is, I need
a vector class with just a few more bells and whistles,
and it's much more convenient to derive from an STL
vector rather than to define a struct that contains the
STL container as a member function. In general, will
the STL algorithms behave properly when iterating
over the elements of a derived container class?
Fred
Neil Butterworth
"Fred Ma" <f...@doe.carleton.ca> wrote in message
news:3E608259...@doe.carleton.ca...
> Hello,
>
> Someone responded on an earlier thread that it isn't
> normal to derive a user-defined container class from
> the STL vector class. This was confirmed by the fact
> that the vector class has no virtual destructor.
>
> Just wanted to check this for sure. Reason is, I need
> a vector class with just a few more bells and whistles,
> and it's much more convenient to derive from an STL
> vector rather than to define a struct that contains the
> STL container as a member function.
Why not write the "bells & whistles" as standalone functions?
In general, will
> the STL algorithms behave properly when iterating
> over the elements of a derived container class?
Yes.
NeilB
Fred Ma
> "Fred Ma" <f...@doe.carleton.ca> wrote in message
> news:3E608259...@doe.carleton.ca...
> > Hello,
> >
> > Someone responded on an earlier thread that it isn't
> > normal to derive a user-defined container class from
> > the STL vector class. This was confirmed by the fact
> > that the vector class has no virtual destructor.
> >
> > Just wanted to check this for sure. Reason is, I need
> > a vector class with just a few more bells and whistles,
> > and it's much more convenient to derive from an STL
> > vector rather than to define a struct that contains the
> > STL container as a member function.
My typo; I meant that deriving from an STL vector is
more convenient than to define a struct that has an STL
vector as a member DATUM (not "function").
> Why not write the "bells & whistles" as standalone functions?
The extra functions and summary data is relevant only to
the body of data contained by the collection, so I want to
keep it in one place. In fact, rather than make standalone
functions, it would probably be preferable to create my own
base class with an STL container as a data member, if I
couldn't derive from the STL container.
> In general, will
> > the STL algorithms behave properly when iterating
> > over the elements of a derived container class?
>
> Yes.
>
> NeilB
I did what I thought was a necessary test (below). What I
was looking for was the possibility that the algorithms take
only standard STL containers. I didn't want them to convert
iterators point to my derived container to iterators pointing
to the baseclass container.
#include <string>
#include <iostream>
#include <vector>
#include <functional>
#include <algorithm>
using namespace std;
typedef vector<int> vecint; // Base class
// The derived class to test
struct T_myvecint : public vecint{
int ExtraInt; // Add-on Bells and whistle member
T_myvecint( const int int_in ) : ExtraInt(int_in) {};
};
// An arbitrary functor that minimally changes
// vector's int elements
void Add3toInt( int &intvar ) { intvar += 3; };
// Functor that extracts container's add-on
// member int from an iterator that points to
// the continer
void PrintAddOnInt( const T_myvecint &mvi){
cout << "for_each extracted ExtraInt=";
cout << mvi.ExtraInt << " from mvi element.\n";
};
int main ( int argc, char** argv)
{
T_myvecint mvi(5);
// The guinea pig object initializes
// the add-on member integer to 5
// Populate the test object with vector elements
for( int i=3; i<10; ++i ) mvi.push_back(i);
cout<<"Before add3:";
for( int i=0; i<mvi.size(); ++i ) cout<<" "<<mvi[i];
cout<<endl;
// Does operator[] work?
// Does begin() and end() work?
// It doesn't make any difference whether
// mvi.begin() is a T_myvecint::iterator or
// vector<int>::iterator, because the only
// difference is an extra member int at the
// container level; iterators have no
// knowledge of their containers.
for_each( mvi.begin(), mvi.end(), Add3toInt );
cout<<"After add3:";
for( int i=0; i<mvi.size(); ++i ) cout<<" "<<mvi[i];
cout<<endl;
// Just another sanity check that iterators
// into mvi containers are recognized and
// can be operated on
T_myvecint::iterator it_myvecint(mvi.begin());
it_myvecint++;
// Now see if iterators that point to entire
// mvi containers can see them as more than
// vector<int> containers and recognize the
// presence of add-on member integer
vector<T_myvecint> v_mvi(4,mvi);
vector<T_myvecint>::iterator vit_mvi(v_mvi.begin());
// Test that iterator is recognized and
// can be operated on
vit_mvi++;
// Test if the extra add-on member is
// seen
cout << "Iterator vit_mvi points to mvi object:\n";
cout << "(*vit_mvi).ExtraInt=" << (*vit_mvi).ExtraInt <<
endl;
// See of for_each doesn't change the
// iterator to plain STL iterator (it must
// see the add-on int in the pointed object)
for_each( v_mvi.begin(), v_mvi.end(), PrintAddOnInt );
};
Output confirms that iterators pointing into the derived
container are treated the same those pointing into the
base container.
Before add3: 3 4 5 6 7 8 9
After add3: 6 7 8 9 10 11 12
Iterator vit_mvi points to mvi object:
(*vit_mvi).ExtraInt=5
for_each extracted ExtraInt=5 from mvi element.
for_each extracted ExtraInt=5 from mvi element.
for_each extracted ExtraInt=5 from mvi element.
for_each extracted ExtraInt=5 from mvi element.
More importantly (from my point of view),
iterators pointing to the derived container itself are not
converted into standard STL containers within the algorithms,
such as for_each.
Anyway, I'm sure the above info is common knowledge
to those who have used the STL for a while, but in view
of Meyers's warning of slicing (in a different context,
admittedly), I thought it prudent to ensure that slicing is
not done by the algorithms on derived containers. Could
prevent a really tedious redesign.
Fred
Peter Koch Larsen
"Fred Ma" <f...@doe.carleton.ca> skrev i en meddelelse
news:3E608259...@doe.carleton.ca...
The danger of deriving from such structures is that if you new an element of
that type and later delete via a pointer to the base, yo have undefined
behaviour.
Thus I would recommend that you do not create such a class for "general
usage", but otherwise everything will be ok.
One approach of reducing the risk of undefined behaviour could be to have
"new" (and "delete"?) private, replacing it with some custopm function.
Kind regards
Peter
josh
> "Fred Ma" <f...@doe.carleton.ca> skrev i en meddelelse
> > normal to derive a user-defined container class from
> > the STL vector class. This was confirmed by the fact
> > that the vector class has no virtual destructor.
> >
> > Just wanted to check this for sure. Reason is, I need
> > a vector class with just a few more bells and whistles,
> > and it's much more convenient to derive from an STL
> > vector rather than to define a struct that contains the
> > STL container as a member function. In general, will
> > the STL algorithms behave properly when iterating
> > over the elements of a derived container class?
barged in and explained why it's not recommended, indeed the destructors are not
virtual, so if you forget the situation and get fancy with your derivees, you're
risking to bump into unforseen and undefined results. If the use context excludes such
events, I guess, you can still do this. But myself, I no longer do that, I am handling
this problem by defining helper functions that take both the container and whatever I
need to do to it as parameters, so that I'm not touching the container itself. Now, if
all you add is such functions you can, of course, safely derive a class, after all, but
how to you ensure it's not ever derived further? That's where a "final"-like keyword
would come in handy, btw, coz, barring the derivation risks, it *is* simpler to derive
an "empty" (safe data-wise) class with a couple of extra functions than add separate
extra code around the container.
Fred Ma
> On Sun, 2 Mar 2003 00:54:30 +0100, "Peter Koch Larsen" <p...@mailme.dk> wrote:
> > "Fred Ma" <f...@doe.carleton.ca> skrev i en meddelelse
> > > Just wanted to check this for sure. Reason is, I need
> > > a vector class with just a few more bells and whistles,
> > > and it's much more convenient to derive from an STL
> > > vector rather than to define a struct that contains the
> > > STL container as a member function. In general, will
> > > the STL algorithms behave properly when iterating
> > > over the elements of a derived container class?
> Yes, and I've done it, and then the same issue came up here, and Andrew Koenig himself
> barged in and explained why it's not recommended, indeed the destructors are not
> virtual, so if you forget the situation and get fancy with your derivees, you're
> risking to bump into unforseen and undefined results. If the use context excludes such
> events, I guess, you can still do this. But myself, I no longer do that, I am handling
> this problem by defining helper functions that take both the container and whatever I
> need to do to it as parameters, so that I'm not touching the container itself. Now, if
> all you add is such functions you can, of course, safely derive a class, after all, but
> how to you ensure it's not ever derived further? That's where a "final"-like keyword
> would come in handy, btw, coz, barring the derivation risks, it *is* simpler to derive
> an "empty" (safe data-wise) class with a couple of extra functions than add separate
> extra code around the container.
Actually, the extra add-ons are actual data objects, not just functions.
So I do run the risk that you describe. Because it is for my personal
thesis research, I'll carefully take that risk (also, since I've spent the
past few days developing code based on that). But thanks for the
heads up. Too bad classes do not accept a switch that determines
whether destructors are virtual (like a template parameter). It would be
handy to have a choice of two such versions of a class (for speed verus
safety), but to have them treated and behave the same otherwise.
josh
> Actually, the extra add-ons are actual data objects, not just functions.
ways to make it safer would probably be to make sure you have only statically defined
instances of your class, and if you need to pass it around, always do it via references
(not pointers, that is.) Not 100% foolproof, but still... no deletion via pointers,
that is. I wonder if it's possible to hack the class up somehow that its new/delete
operators aren't accessible, or something like that... so that it's impossible to
create instances dynamically.
Fred Ma
I changed my mind. The last thing I need to do is to spend who knows
who much time hunting down memory leaks, so I recoded to avoid
nonsafe derivation from vector<>. The vectors are now member data
rather than base classes. Thanks.
Fred
Peter Koch Larsen
"josh" <jos...@aol.com> skrev i en meddelelse
news:1104_10...@news.netcarrier.net...
that I supplied. If you'd care to take an extra look, You'll notice that my
proposal was precisely to provide your own new and delete.
/Peter
Fred Ma
Hi, Peter,
I did read your response, and appreciate your suggestion.
The content was snipped because I responded to a response
to your post, and it was already snipped. The reason why I'm
taking the more conventional way out (by not deriving from a
class), is because overloading new/delete is rather
unconventional (albeit in my limited experience), so I don't
feel comfortable exploring that alternative right now. In fact,
because new and delete don't have the syntax of normal
functions, I didn't even know it could be overloaded. I'll have
to read up on that in more detail, and think about the
implications (if there are any). For now, I want to resort to
clunkier to better understood methods (by me, that is) because
of time constraints. But just to know that it can be done is
useful, even if I don't follow up on it right now.
Thanks again.
Fred
Shing-Fat Fred Ma
-------- Original Message --------
Subject: Re: Deriving from STL container
Date: Mon, 03 Mar 2003 19:07:27 -0500
From: Shing-Fat Fred Ma <f...@doe.carleton.ca>
To: Noel...@morganstanley.com
Noel Yap wrote:
> I believe the problem is worse than memory leaks (ie undefined
> behaviour) and will only occur if you have something like:
> std::vector< int > *pi = new my_vector< int >;
> delete pi;
>
> For example, I've recently found that RogueWave has plenty of
> superclasses with non-virtual destructors, but it's never a problem
> since the usage of these classes don't involve polymorphism. OTOH, I'm
> not sure if they've declared new and delete as private just to avoid
> accidents.
>
> HTH,
> Noel
Not sure why the above code is a problem, as long as my_vector
is safely derived from vector i.e. no extra member data, just extra
member functions.
Fred
--
Fred Ma, f...@doe.carleton.ca
Carleton University, Dept. of Electronics
1125 Colonel By Drive, Ottawa, Ontario
Canada, K1S 5B6
Neil Butterworth
"Shing-Fat Fred Ma" <f...@doe.carleton.ca> wrote in message
news:3E63EF4B...@doe.carleton.ca...
> Forgot to copy the following to the newsgroup...
>
> -------- Original Message --------
> Subject: Re: Deriving from STL container
> Date: Mon, 03 Mar 2003 19:07:27 -0500
> From: Shing-Fat Fred Ma <f...@doe.carleton.ca>
> To: Noel...@morganstanley.com
>
> Noel Yap wrote:
>
> > I believe the problem is worse than memory leaks (ie undefined
> > behaviour) and will only occur if you have something like:
> > std::vector< int > *pi = new my_vector< int >;
> > delete pi;
> >
> > For example, I've recently found that RogueWave has plenty of
> > superclasses with non-virtual destructors, but it's never a problem
> > since the usage of these classes don't involve polymorphism. OTOH, I'm
> > not sure if they've declared new and delete as private just to avoid
> > accidents.
> >
> > HTH,
> > Noel
>
> Not sure why the above code is a problem, as long as my_vector
> is safely derived from vector i.e. no extra member data, just extra
> member functions.
The standard says that deleting a derived class through a base pointer gives
undefined behaviour if the base does not have a virtual destructor. Period.
It says nothing about the derived class having "no extra members" or "just
extra member functions". It also says nothing about "memory leaks" in this
situation.
NeilB
Fred Ma
> > Noel Yap wrote:
> >
> > > I believe the problem is worse than memory leaks (ie undefined
> > > behaviour) and will only occur if you have something like:
> > > std::vector< int > *pi = new my_vector< int >;
> > > delete pi;
> >
> > Not sure why the above code is a problem, as long as my_vector
> > is safely derived from vector i.e. no extra member data, just extra
> > member functions.
>
> The standard says that deleting a derived class through a base pointer gives
> undefined behaviour if the base does not have a virtual destructor. Period.
> It says nothing about the derived class having "no extra members" or "just
> extra member functions". It also says nothing about "memory leaks" in this
> situation.
>
> NeilB
Drat. I just spent the last little while converting a class to a derivative
of vector (rather than containing a vector data member) because I thought
it was safe if all the extra members are functions only. Just wondering,
before I change it back (the edits and debugs are intertwined with
other stuff, so I can't just go back to an earlier snapshot), how much
does it matter in practice? If this is strictly unpredicatable, I will change
it back. If in general, it's harmless, I won't. Actually, I'll be OK as long
as
I don't delete a derived class object via a base class pointer (fingers
crossed).
Fred
Neil Butterworth
It matters if you want your code to be portable and compliant with the
standard.
> If this is strictly unpredicatable, I will change
> it back. If in general, it's harmless, I won't. Actually, I'll be OK as
long
> as
> I don't delete a derived class object via a base class pointer (fingers
> crossed).
Quite - if you don't do this, you are OK.
NeilB
Fred Ma
> > Drat. I just spent the last little while converting a class to a
> derivative
> > of vector (rather than containing a vector data member) because I thought
> > it was safe if all the extra members are functions only. Just wondering,
> > before I change it back (the edits and debugs are intertwined with
> > other stuff, so I can't just go back to an earlier snapshot), how much
> > does it matter in practice?
>
> It matters if you want your code to be portable and compliant with the
> standard.
It's as portable as gcc. That's enough for me. (It's thesis research.
If it becomes the greatest commercial product since slice bread,
then I'll worry more about portablility ;) ).
> > If this is strictly unpredicatable, I will change
> > it back. If in general, it's harmless, I won't. Actually, I'll be OK as
> long as
> > I don't delete a derived class object via a base class pointer (fingers
> > crossed).
>
> Quite - if you don't do this, you are OK.
>
> NeilB
Thanks, Neil.
Fred
E. Robert Tisdale
> Someone responded on an earlier thread that
> it isn't normal to derive a user-defined container class
> from the STL vector class.
> This was confirmed by the fact that
> the vector class has no virtual destructor.
Pure FUD!
http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?query=FUD
If you want a virtual destructor,
just derive a class from a template class
that has a virtual destructor
and use that as a base class
for all of your polymorphic function definitions.
Rob Williscroft
> Fred Ma wrote:
>
>> Someone responded on an earlier thread that
>> it isn't normal to derive a user-defined container class
>> from the STL vector class.
>> This was confirmed by the fact that
>> the vector class has no virtual destructor.
>
> Pure FUD!
>
> http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?query=FUD
>
This sounds like Common Sense(tm)
> If you want a virtual destructor,
> just derive a class from a template class
> that has a virtual destructor
Sorry? how does deriving from a template class help.
> and use that as a base class
> for all of your polymorphic function definitions.
Again? 'base of ... function definitions' How does that work?
Rob.
josh
irrelevant to the topic.
Fred Ma
I'm deriving from the vector template class, which
has no virtual destructor. Sure, I can give my
derived class a virtual destructor, but that's no
guarantee that any descendant objects will not
be pointed to by a vector pointer. The best that
I can do is to promise that I'll never point to a
vector derived object using a vector pointer.
I know enough about me not to trust myself on
those promises. Also, Neil was mentioning that
deleting a derived object via a base class
pointer is guaranteed undefined behaviour,
if the base class has no virtual destructor.
Apparently, this is true even if the derived class
only adds member functions (no member data).
I have a dream. I dream of the day when the
compiler slaps you on the wrist for pointing at
a derived object with a base class pointer, if the
base class pointer has no virtual destructor.
Wouldn't that be heaven? You can go ahead
and mix and match stuff and be assured that
you won't be allowed to do anything stupid.
Otherwise, there's always this price tag attached
to polymorphism, either the speed degradation of
virtual destructors, or the gamble of not having
them.
Fred
josh
inheritance of by inclusion, and then provide a conversion operator or a special
function so that your class could still be used in STL algorithms and stuff? Kill two
birds with one stone sorta thing.
Alexander Terekhov
"E. Robert Tisdale" wrote:
[...]
> Pure FUD!
>
> http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?query=FUD
http://groups.google.com/groups?selm=35d45c49.2132556%40news.prosurfr.com
(Subject: Re: by the way, what the hell is FUD ? :) )
"....
The tactic, of course, wouldn't be effective if it wasn't true that
sometimes those things are _worth_ worrying about."
http://www.computerworld.com/industrytopics/manufacturing/story/0,10801,52613,00.html
(Amdahl planning to exit mainframe business)
http://www.techweb.com/wire/story/TWB20001019S0017
(Amdahl Ditches Mainframes)
regards,
alexander.
Shing-Fat Fred Ma
> Fred Ma wrote:
> >
> > Neil Butterworth wrote:
> >
> > Drat. I just spent the last little while converting a class to a derivative
> > of vector (rather than containing a vector data member) because I thought
> > it was safe if all the extra members are functions only. Just wondering,
> > before I change it back (the edits and debugs are intertwined with
> > other stuff, so I can't just go back to an earlier snapshot), how much
> > does it matter in practice? If this is strictly unpredicatable, I will change
> > it back. If in general, it's harmless, I won't. Actually, I'll be OK as long
> > as
> > I don't delete a derived class object via a base class pointer (fingers
> > crossed).
>
> Pedantically, I would never do it. Pragmatically, if your compiler
> documents the behaviour, you may be able to get away with it /for now/.
> OTOH, searching compiler docs may take more time than making sure
> everything's AOK with the standard.
>
> The last situation should be fairly easily grep'able.
>
> Noel
Actually, if I don't delete via a base class pointer, it should be
OK. If I ever need to do that, I can redesign the class internally.
Fred Ma
Josh,
Hope you'll excuse my inexperience here, but could you
provide a short example of what you mean, and how it
helps?
Thanks.
Fred
A Cappella Guy
the relationship, use private inheritance. You get stronger coupling,
which is usually to be avoided, and you have to publicize the members
with using directives, but it's a valid approach.
template <class T> class LikeAVector : private std::vector<T> {
public:
using std::vector<T>::begin;
using std::vector<T>::end;
void NewFunction(int arg);
void AnotherOne();
};
-- A Cappella Guy
Attila Feher
> Actually, if I don't delete via a base class pointer, it should be
> OK. If I ever need to do that, I can redesign the class internally.
It is always a tradeoff with classes you cannot touch. :-( If it would be
your own class, you could make operator delete in the base private and
undefined. But with standard classes one must balance between delegating
the whole interface to a member or using this unsafe inheritance. It is
important to note that when Stroustrup inherits from vector he only hides
the operator[]s of the vector and adds nothing, which should change the
functionality of the destructor. In real life, I guess nothing ensures in
the C++ standard this. But if one adds new members (needing destruction)
one is on clear way to trouble - especially in a large development
team/project. There is no way to *ensure* that noone will ever call delete
via base. :-(
A
Attila Feher
I would rather make the vector to be a member. Read more about it in More
Exceptional C++.
The above is the other solution, but in this case one must delegate all the
functionality of the vector interface.
A
Fred Ma
I'm not sure what you mean by delegating all the functionality
of the interface. Perhaps you mean I have to write a LikeAVector
member function for every vector member function I want to access.
Yes, that sort of kills the convenience of deriving from vector
versus having a vector as a public member.
Fred
Attila Feher
> I'm not sure what you mean by delegating all the functionality
> of the interface. Perhaps you mean I have to write a LikeAVector
> member function for every vector member function I want to access.
> Yes, that sort of kills the convenience of deriving from vector
> versus having a vector as a public member.
Real programmers don't use public members. :-)
I have meant public inheritance vs. private inheritance or private member.
In the first case no delegators are needed. BTW on many compilers if you
inherit (instead of making a member and delegating) you will get one warning
message for each redefined memebr function saying: function Buu in class X
hides Buu from class Base. Quite bad if you want code with no warnings.
A