Re: [boost] [uuid] Interface

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
>> 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
C++0x.

>>> 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
views.

> 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
http://www.boostpro.com