Sign in to follow this  
pragma Fury

Deriving from STL containers

Recommended Posts

pragma Fury    343
I've heard from several sources that this should be avoided, and the reason given was always because the STL container classes do not have virtual destructors. Obviously, this can cause undefined behavior if you delete a base pointer to your derived class:
class Dictionary : public std::map<std::string, std::string> {
//...
};

std::map<std::string,std::string>* pBaseContainer = new Dictionary();

delete pBaseContainer; // undefined behavior

Are there any other good reasons why one should not derive from one of the STL container classes? I can't think of any.

Share this post


Link to post
Share on other sites
Sneftel    1788
The big reason is that, as a general rule, inheriting from a container happens when a programmer doesn't understand when to use inheritance and when to use composition. The situations in which publically inheriting from an STL container is actually the right thing to do are few and far between. What is your particular application?

Share this post


Link to post
Share on other sites
pragma Fury    343
No particular application at the moment. I've seen this done at work in a few projects, and was wondering if there were some reason one should never derive from an STL container. ie: memory leaks, undefined behavior, etc.

Share this post


Link to post
Share on other sites
snk_kid    1312
Quote:
Original post by pragma Fury
I've heard from several sources that this should be avoided, and the reason given was always because the STL container classes do not have virtual destructors. Obviously, this can cause undefined behavior if you delete a base pointer to your derived class:


Yes but if your not invoking delete on pointers to base types its fine so its just a myth that you should always avoid it, in some cases it may make sense and there is nothing wrong with it but standard library containers are not polymorphic types because of efficiency reasons therefore generally not be used polymorphically.

Yes you can even override non virtual member functions however dynamic dispatch/binding does not work so invoking a non virtual member function on a reference/pointer to a base type that refers to an instance of a derived class that overrides that member function wont dynamically bind to the derived version.

Quote:
Original post by pragma Fury
Are there any other good reasons why one should not derive from one of the STL container classes? I can't think of any.


This isn't really reason to avoid it but general advice, if rely on implementation details then your subclass is not portable as long as you don't do that then your fine.

[Edited by - snk_kid on June 28, 2005 7:55:35 PM]

Share this post


Link to post
Share on other sites
Deyja    920
Simply put, you should never derive from a class that was not designed with that in mind. STL Containers were designed with the thought that no one should ever derive from them in mind. The only time I've ever seen this actually done was when someone wanted to add an algorithm that operated on list. I rewrote it as an algorithm that operated on iterators - and replaced several of the lists with vectors.

Share this post


Link to post
Share on other sites
mattnewport    1038
The only valid reason to derive from a class with no virtual destructor is to inherit implementation rather than inherit interface1. When you are inheriting implementation you should generally use private inheritance - that's the C++ way to say you are not inheriting interface and you are not modelling an 'is a' relationship, rather your derived class is 'implemented in terms of' the private base. In most cases however you should use composition rather than private inheritance to reuse functionality provided by existing classes. Take a look at Herb Sutter's discussion of the issue.

[edit] 1Actually, that's not quite true - there are other cases where you might want to inherit from a class with no virtual destructor. The standard library std::unary_function class is one example.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this