On Sat, Feb 26, 2005 at 07:55:18PM -0700, Jeff Garland wrote:
On Fri, 25 Feb 2005 18:26:22 +0000, Jonathan Wakely wrote
christopher diggins wrote: I think publicly inheriting from a class that isn't designed for inheritance is a bad idea. There are type safety problems, non-virtual destructors, slicing etc.
Hi Daniel thanks for the help and suggestions ( and Kevin and Jonathan as well),
I have heard here and there, inheriting from STL container is a "bad idea", but I don't specifically know all the reasons why. I am not an expert in this area (heck or any part of C++ for that matter). Isn't it only bad if someone tries to delete the object using a base class pointer?
That's one reason, yes.
(btw, this is Item 35 in Sutter and Alexandrescu's C++ Coding Standards)
At the risk of going against the entrenched dogma here, I'd suggest there are significant cases where this is a good and useful thing to do.
I'm certainly not dogmatic about it and wouldn't turn my nose up at your date-time example, I think it makes sense in that case. Christopher asked about macros to help derive from STL containers specifically, which I do think is usually a bad idea and not something to be encouraged by a Boost library that makes it easy (IMHO). There are some situations, such as Christopher's PwC library, where it might be OK, but I think those situations are rare.
original guidance came from Scott Meyers Effective C++ #14 -- make destructors virtual in base classes. The problem I have with this is that I find there are plenty of situations where I might want to add some convenience functions to an stl container in which the subclass has a trivial destructor (eg: no allocated resources) and as such there is no issue with deriving from container. In all cases I know the base class destructor is called and hence anything the container allocates will be deallocated.
Why do the convenience functions have to be member functions? If you inherit from STL containers you can't be making use of any protected functions or data, since that would rely on details of a particular STL implementation. You might have good use cases for doing it and know what you're doing, but there are plenty of programmers out there who don't. jon