Re: [boost] [UUID] Code for UUIDs as PODs and other changes

Subject: Re: [boost] [UUID] Code for UUIDs as PODs and other changes
From: Scott McMurray (me22.ca+boost_at_[hidden])
Date: 2008-12-06 22:53:46

On Sat, Dec 6, 2008 at 21:12, Vladimir Batov <batov_at_[hidden]> wrote:
> ...
>> >> uuid u = { /* 6ba7b814-9dad-11d1-80b4-00c04fd430c8 */
>> >> 0x6b, 0xa7, 0xb8, 0x14,
>> >> 0x9d, 0xad,
>> >> 0x11, 0xd1,
>> >> 0x80, 0xb4,
>> >> 0x00, 0xc0, 0x4f, 0xd4, 0x30, 0xc8
>> >> };
>> >
>> > I am not sure as a user I'd be interested in doing that kind of low-level stuff and in fact I am doubtful it'll even compile.
>> >
>>
>> It does work, actually. I use it to implement
>> uuids::namespaces::dns() and friends.
>
>
> It compiles indeed! Tried MSVC++9 and even ol' gcc 3.4.4. C++0X talks about initialization of that kind but for standard containers. To me it feels like very non-standard behavior. What am I missing? Someone help me out here.
>

It comes from making it a POD, as all PODs are also aggregates.

8.5.1 Aggregates [dcl.init.aggr]

An aggregate is an array or a class (clause 9) with no user-declared
constructors (12.1), no private or protected non-static data members
(clause 11), no base classes (clause 10), and no virtual functions
(10.3).  When an aggregate is initialized the initializer can contain
an initializer-clause consisting of a brace-enclosed, comma-separated
list of initializer-clauses for the members of the aggregate, written
in increasing subscript or member order. If the aggregate contains
subaggregates, this rule applies recursively to the members of the
subaggregate.

Boost.Array is also an aggregate
(http://www.boost.org/doc/libs/1_37_0/doc/html/array/rationale.html),
so the initializer works by initializing the subaggregate, with the
excess braces elided following 8.5.1/11.

Value-initialization of unspecified members (8.5.1/7) gives another
way to get the nil UUID:

    uuid u = {};
    assert(!u);

(These rules are also why I removed the boost.operators usage, since
even empty base classes run afoul.)

>>
>> I'm not particularly attached to nil(), but at the same time, I don't
>> have any better name. I dislike null(), when people are used to
>> treating NULL as pointer (even when it actually isn't). C# uses
>> Empty, but that's also not great, since empty is strongly entrenched
>> through its use in the Container concept.
>
> Fair enough. The standard expicitly mentioning uuid::nil() sounds like a good reason.
>
>> Really, I'd be plenty happy to get rid of it entirely, since value
>> initialization provides the same functionality: uuid id = uuid();
>
> Have to disagree as to me the above is unclear as I am not sure if it means "create a new uuid" or "create an invalid uuid". I prefer saying clearly what I mean, i.e. uuid id(uuid::nil());
>

True.  If the review has made anything clear, it's that explicit is best.

Best,
~ Scott