extending an STL container class Question

[wien]

and it would be great to get some comments from them about the things pointed out by SuperKoko.

Ask, and ye shall recieve.

No, public inheritance always means "IS-A", and it is known by the user, because the user can use the derived object like a base object. That means that the user can use all the member functions of the vector.

private inheritance can be an implementation detail, but public inheritance, is never an implementation detail.

I was talking about the CRTP (Curiously Recurring Template Pattern) classes in boost, not the event_list/vector relationship. They are used to implement a lot of member-function s "on behalf" of classes inheriting from them. boost::iterator_facade for example implements all the operators an STL iterator needs, based on four functions (increment, decrement, equal and dereference) implemented in the derived class. This is done without any kind of polymorphism (run-time that is), and the CRTP classes will never be used in client code, and certainly not to achieve any kind of polymorphism.

In those cases I would consider public inheritance an implementation detail, and thus, not a case of IS-A.

About virtual destructors, you must know that it is really useless to declare virtual destructors in classes that have no virtual functions.
Let me explain.<snip>

Well, yes. But to make a class meant to be used as a base class, without any virtual functions is somewhat of a design-flaw in my opinion. What would then be the point in deriving from it? Code reuse? In that case I refer to the quotes Graham posted.

Furthermore, nothing is preventing users from deleting a derived object through a pointer to the virtual-less base, so that could still lead to problems. (I admit the chance of that happening is very slim with no polymorphism possible, but as I have said before, that doesn't make it okay. People do strange things sometimes, and it's always better to try to limit their possibilities to do so.)

So, you may think. Why the std::vector implementation of the STL has not virtual members for all his members.
There are two responses:
1) Performance will be very, very bad.
2) A vector is not designed to be derived polymorphically.
Who wants to derive from std::vector, and redefine the operator[] and use polymorphically pointers to the old std::vector, and pointers to the new derived class? At least if there were an abstract base class containing the vector operations, it would have a meaning, but since all the implementation of std::vector is contained in the vector, you are constrained to loose all the memory space of the vector implementation if you want to derive from it and use another implementation.

The primary reason STL containers don't have virtual members, is that their design are not really based on OOP at all, but rather generic programming. The Container/Iterator/Algorithm concepts introduced in the STL give us a much better way of extending it's functionality, rendering inheritance more or less useless for that purpose.