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

From: Jeff Garland (jeff_at_[hidden])
Date: 2005-02-27 14:56:58

On Sun, 27 Feb 2005 11:50:32 +0000, Daniel James wrote
> You're the designer of the base class - so it is designed to be 
> inherited from. You're not overriding the public interface, so 
> you'll get the same behaviour from the base class and the derived 
> class. I wouldn't feel great about this code, but I find it hard to 
> come up with a really convincing argument against it.

Well, then I think I shouldn't feel bad about it ;-) In fact I should be happy
that I'm able to express the design concisely and correctly. 
 
> I suppose there are alternatives: a function which returns 
> time_duration 
> (but then you can't overload on the type) or a class with conversion 
> operators to time_duration (but that falls down when a function 
> overload requires more user-defined conversions).

Right -- see my other response for more.

> If you wanted to do something like this, but were worried about it,
>  how much work would it be to remove all possibilities of undefined 
> behaviour?  At least under reasonable use, that is. Or is it even 
> possible? I suppose you'd have to make operators &, new and delete 
> protected, anything else? (I'm thinking about something along the 
> lines of boost::noncopyable).

Well I think I'll need an example of a problem case to prevent.  Haven't found
one yet -- nor have the users of date-time. I think that there aren't any real
cases and that the 'standard guidance' could use some extension.
 
> Jeff Garland wrote:
> > I'd say there is something about writing less code (not laziness) that makes
> > it a better design.  Having to forward or reimplement the whole interface of
> > an stl container is non-trivial and probably a bad design.
> 
> In Christopher's use case, he's wrapping most of the member 
> functions anyway.

Ok, in that case there isn't an advantage.

Jeff