Thread: Inheritance from STL container

Do not inherit from standard containers, they simply were not designed to be base classes (hence the lack of a virtual destructor).

Just a thought: Instead of deriving your class form std::list, you could override the & opperator to return a list pointer. Then you would need to implement all of the meathods of list yourself (perhalps by including a list object that the meathods would be forwarded to). Simmilarly you could override opperator& to return a spcial object that can be cast to a list pointer, but by itself also has aditional functionallity, such as calling meathods that are not part of std::list.

Is there any reason to have a custom list container in the first place? Why not just have the wrapper object use a std::list? Or if you really need to, write a wrapper for std::list to replace the current custom list container.

I am starting to think that a wrapper that implements the std::list API functions, where the wrapper implementation calls the std::list implementation via the Wrapper::std::list mList member variable might be the best way around this issue...

Yes, that is what I had in mind, given your restrictions.

Another option is private inheritance, which avoids the non-virtual destructor issue and makes exposing the list class easier by allowing you to do things like:

Code:

class custom_list : private std::list
{
public:
  using std::list::size;
  using std::list::empty;
  // etc.
};

Another option is to not create a custom list class at all. If you deprecate the third party custom container and replace it with your own custom list, then the current users will have to change their code anyway. You could just allow them to use the actual standard library containers, and add functionality through non-member functions (similar to the standard algorithms). This has the added benefit of allowing flexibility as far as which container to use. Depending on your scenario, it is possible that a vector or deque might be more appropriate than a list, and well written non-member functions will be able to handle any of those.

If you do write your own class, consider making the underlying container a template type that defaults to std::list to provide that flexibility. I don't know your requirements, so maybe a list will always be the right choice, but it is something to think about.

Does the template wrapper in the legacy code delete objects on destruction?

You may want to use Boost.Ptr_Container instead of writing your own solution.