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