Re: [boost] [uuid] Interface

Subject: Re: [boost] [uuid] Interface
From: Scott McMurray (me22.ca+boost_at_[hidden])
Date: 2008-12-23 17:57:55

On Tue, Dec 23, 2008 at 01:24, Vladimir Batov <batov_at_[hidden]> wrote:
>
> Just for clarity I'll state the obvious -- in your example 'm_uuid' *is*
> initialized. Only built-in types allow declaration without definition (as a
> place holder). Classes do not allow that behavior. Classes always require
> and call constructors.

"Declaration without definition" is extern.  I think you mean
uninitialized, which *is* allowed in classes, if they're aggregates.
I've already uploaded a version that does exactly that.

> Therefore, IMHO making them *look* like they behave
> similarly to built-ins sends/enforces the wrong message/impression.

So why not make them behave like them?  I've always heard "do as the
ints do" as the guideline for value types.

> Therefore, I prefer the following which does exactly the same -- 'm_uuid'
> initialized invalid -- but explicit about what it actually does.
>
> [code snip]
>
> As for efficiency I expect this variant to be at least as efficient (if not
> better) because uuid::nil() is likely to have and to return the same
> initialized-once instance
>

I'd be very suspicious of that claim.  The cache miss for going to get
that instance could well be worse.

> i.e. no byte initialization traversal

If you allow a constructor for making the nil value (obviously I would
like the default constructor, but a function pointer so you could do
uuid(uuids::nil) would be fine in your way), then there's no need for
uuid::nil() to have a loop, since it can value-initialize the member
array (which is an aggregate) letting the compiler use the most
efficient zeroing method it has.

Also, in a situation where the constructor logic is unneeded, it's
possible to completely remove one that simply value-initializes.  The
compiler can never remove calls to a global static PRNG (which has
cache and threading consequences, too).