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
> (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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk