Boost logo

Boost :

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" <> 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
>> somewhat.
> 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
default-constructability rule.

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
> non-conformance)?

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at