Boost logo

Boost :

Subject: Re: [boost] [uuid] Interface
From: Vladimir Batov (batov_at_[hidden])
Date: 2008-12-23 02:38:54

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

Yes, I know. It was a typical statement when one gives you 2 choices when
one is clearly out of question, i.e. you are in fact presented with no
choice at all.

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

I suspect it is worse. If a class cannot create a valid instance with a def.
cnstr, then such an instance is essentially invalid, i.e. we are getting
closer to the condemned "declaration without definition" behavior of the
built-ins. More still, given we've open up a possibilty of incorrectly
initialized object, we'll have to have additional checks throughout the code
if the instance (or parts of it) is indeed valid.

> However, for move semantics (and what could be more suited to that than
> a UUID?)

Well, actually I am not sure UUID is a really good candidate for move
semantics -- it's just 16 bytes, self-contained, really cheap to copy. Move
semantics makes sense for really big and expensive-to-copy objects. Still,
I've been getting-by by passing by-reference or enveloped in auto_ptr or

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

Well, from my mole-hill the medicine seems worse than the problem. If we
truly need such a "special" state, I'd expect we say so explicitly and have
something like foo::bad, foo::invalid, foo::uninitialized in general terms
rather than hijack the def. cnstr. That way, we'd indeed mimic the
"declaration without definition" built-in behavior without disrupting the
status-quo. That uninitialized/invalid state could be used for the move

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

I did not mean to question the importance of Stepanov's view. :-) I meant to
ask how big an impact that view might have for developers-practitioners.


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