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

From: Jeff Garland (jeff_at_[hidden])
Date: 2005-02-27 15:15:15

On Sun, 27 Feb 2005 13:11:11 -0500, christopher diggins wrote
> > 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 think the
> > 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)
> 
> I am a little confused here, does MySubClass below have a "trivial" 
> destructor?
> 
>   MySubClass : MyBaseClass {
>     int x;
>   };
> 
> In other if I write:
> 
>   MyBaseClass* p = new MySubClass;
>   delete p;

No leak here.  It's only in the case that you allocate in the subclass that
there is a problem.
 
> Do I leak the memory for integer x? And then what happens here:
> 
>   Baz {
>     ~Baz() { cout << "destroying baz"; }
>   };
> 
>   MySubClass : MyBaseClass {
>     Baz x;
>   };
> 
>   MyBaseClass* p = new MySubClass;
>   delete p;
> 
> Does the baz get destroyed? I always assumed it should.

I didn't try it, but I believe the memory for Baz will be released but the
destructor won't be run. It would get bad if you allocated in Baz which would
be easy enough to introduce by accident in a real design.  Hence the guidance
not to go down this path...

> >> If you want to inherit from, say, vector, do you _really_ want _all_
> >> its public member functions?
> >
> > Yes, I frequently do.
> >
> > Jeff
> 
> So Jeff, would you find a set of macros for facilitating the 
> inheritance of STL containers useful?

I don't think so.  See my other response for how I limit my extensions.  Also,
I really hate macros for doing these sorts of things because I have to reverse
engineer what the macro is doing when I need to read the code.  At a minimum
that means I need to go to another file, try and grok whether the macro
applies to what I'm doing, mentally add in whatever functions/types it
creates.  I'm getting too old for these sorts of mental gymnastics -- I'd
rather have the code just written out.  Now if you had policy-based
collections that would support full inheritability as an option and
implemented standard container interfaces -- that might be interesting ;)

Jeff