Re: [boost] [uuid] Interface

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

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

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

Best,
V.