extending an STL container class Question

[wien]

If the ISO Standards Committee would have believed that public inheritance without dynamic binding is risky to use, it would have made dynamic binding the default for public inheritance and left no other alternative. However, the use of dynamic binding has a conisderably high overhead and its overuse can affect a program's performance.

That's not what I'm saying. Public inheritance is useful for many things where virtual destructors (and thus polymorphism) are not needed. The many Boost CRTP classes (like for instance iterator_facade) are excellent examples of that. This is in fact a case where I disagree somewhat with the whole "public inheritance means IS-A" thing. I wouldn't say inheriting from boost::iterator_facade means my class IS-A (Or would it be IS-AN?) iterator_facade, and I certaily wouldn't exploit that polymorphically. The public inheritance in that case is an implemetation detail, and shouldn't even be known by the user.

What I am saying, is that if both the base, and derived classes are in the public and documented interface of the library/whatever you're developing (like in the case of vector and event_list), then the users should be able to use them polymorphically. (Yes, even delete through a base pointer.) If the hierarchy cannot be used polymorphically, you should hide the base class from the users and call it an implementation detail. (Which of course you cannot do with std::vector.)

Sigh.. Maybe it's just me...

One thing I always liked about C++ as a language is that, unlike Java, you don't have to pay for what you don't need.

I quite agree.

This is one of those cases where using dynamic binding is not necessary because no one in their right mind would ever use a pointer to a container, never mind assign a derived class object to it and then try to delete the derived class object through the pointer.

Well... Noone would do that knowing containers don't have virtual destructors. The problem is, not everybody knows that, so why open up for the possibility? Like others have pointed out, there are better ways of extending the functionality of containers. Inheriting from them is just not needed.

The interfaces are the same: the OP hasn't redefined a single vector member function. He simply has added functionality in what I believe is the proper way to do so.

I disagree. The proper way to do so, would be through non-member functions.

Anyone who would try to use a vector<Event>* to point to an event_list object would know that the base class is vector. And everyone should know that STL classes do not have virtual destructors.

In this specific case most people would know that, yes. But that doesn't make it okay. I don't think this should be required information for people simply using your vector inherited class.

In the more general case, if I made a class with no virtual destructor (thereby signalling "don't inherit from this one"), and you did anyway, other programmers would not know that, and they would probably assume polymorphism is safe. (I certainly would) Why should people have to check my base class for a virtual destructor before they use it polymorphically?

However, as I asserted above, no one would ever need to do such thing, so their knowing or not knowing whether vector has a virtual destructor is not a problem in the first place.

How do you know that? Someone might need to do that... You just don't know.

I think the central idea here is that there is a difference between public inheritance and polymoprhism. Public inheritance does not always mean polymoprhism. It simply means IS-A.

Yes.. And in my opinion IS-A means polymorphism, but public inheritance does not *always* mean IS-A (Sorry Graham! ) That's where we disagree I guess.

The reason the STL writers did not make the STL containers have virtual destructors is because they saw the containers unfit for use is a polymorphic situation (not because they saw them unfit for public inheritance - there is a difference).

Are you sure that is really what they meant? I would really like to see a quote to that effect if they do. As far as I have been able to gather, no virtual destructor means "do not inherit".

Yet you try to question this, and manage to come up with these highly unlikely scenarios where people would go against the design intended by the STL writers and try to (wrongly) use STL containers in a polymorphic way. Well, bad design has its consequences. In this case, trying to use vector, a well-known class in the standard library, polymorphically even though it's clearly not meant to be used so, may lead to undefined behaviour. So why worry about the trouble people get into when they use a bad design?

The point is that you are shifting a big resposibillity over to the users of your class. If everyone did that we would have to check any base classes for virtual destructors every single time we use them polymorphically. Do you do that?

If you instead just say IS-A means polymorphism and that public inheritance only means IS-A if the base class is available to the users, then they just don't have to do this anymore. It takes away quite a few possibilities for errors made by programmers. (Always a good thing)

Phew.. I don't know. Am I making myself a little clearer now?