Re: [boost] Re: Querying usefulness of a macro for inheriting from STLcontainers

From: Jonathan Wakely (cow_at_[hidden])
Date: 2005-02-28 03:27:10

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