Subject: Re: [boost] [uuid] Interface
From: David Abrahams (dave_at_[hidden])
Date: 2008-12-22 18:14:02
on Sun Dec 21 2008, "Vladimir Batov" <batov-AT-people.net.au> wrote:
>>> I searched high and low and I was not able to find any hints about
>>> equivalency of the default-constructed objects (required, expected,
>>> assumed or otherwise). And I am still under impression that that
>>> requirement (or expectation) cannot be real as many classes are not
>>> even meant to be comparable.
>> I believe the general consensus about that is changing, at least
> Dave, would you please elaborate? In what "direction" that is changing? Are there
> plans to single the def. cnstr out and to impose some
> restrictions/requirements/assumptions onto it?
Not exactly, but concept Regular is going to be an important one in
>>> I do not think it makes them unusable with the std containers or
>>> breaking anything or second-class classes of no interest to the
>>> Standards committee.
>> You might Google for 'stepanov "regular types"'
> Thank you for the pointers. I was able to download "Fundamentals of Generic
> Programming" and there they clearly consider the def. cnstr one of the fundamental
> operations for built-in types that they are extending on to "regular types". I have to
> say that my initial reaction is of a surprise. I would expect it the other way around
> -- I'd try making built-in types behave more like "normal" classes
? You don't get to change the way built-ins work.
> or if we cannot do that for backward compatibility reasons, then
> acknowledge the difference and get on with it. Dragging "normal"
> classes down and squezing them in to the the procrustean bed of the
> built-in types (dragged into the present through C compatibility)
> seems like a step down.
I admit I'm ambivalent about that too. The ability to cheaply
default-construct an object is so seldom important, and strong
invariants are so valuable, that I am reluctant to adopt the
However, for move semantics (and what could be more suited to that than
a UUID?) the invariant often needs to include a "empty" moved-from state
anyway, and you could argue that one might as well implement a cheap,
non-throwing default ctor that produces that state. The argument I
sometimes use against it is that even though the empty state technically
becomes part of the class invariant, limiting that state to moved-from
objects still offers some improved ability to reason about code... but
that's a weaker argument than I'd like.
> I am not sure of the practical importance of that Stepanov's view
Personally, I'm wary of underestimating the importance of Stepanov's
> as in many years of writing code I always followed the view of only
> introducing necessary constructors and I do not remember being
> hampered by the fact that those classes were not "regular types". What
> in your view is the importance of t hat "regular type"-conformance (or
I'm still trying to form an opinion on it. Certainly the
copy-constructability, assignability, and equality comparison
requirements are required for equational reasoning. Default
constructability doesn't rise to the same level of importance for me,
but I'm still unsure.
-- Dave Abrahams BoostPro Computing http://www.boostpro.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk