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 20:22:04

On Sat, Dec 6, 2008 at 19:49, Vladimir Batov <batov_at_[hidden]> wrote:
>> PODness:
>
> I am personally far from thrilled and fail to see benefits of that move.
>

I was considering the possibilities of using them straight out of
memory mapped files, or other such things.

The PODness was mostly an impetus to cut down the uuid class itself;
I'm also unsure of whether it's a worthwhile change to keep.

>> As a POD, all the constructors are of course gone.
>
> Well, "constructors are of course *not* gone" as the default and copy constructors will be generated for you. The auto-generated default constructor does not seem to initialize the underlying boost::array to anything. Therefore, I suspect "uuid id;" will be left uninitialized.
>

Correct, that was insufficiently rigorous of me; I should have said
custom constructors.  A POD does not have a default constructor, and I
mistakenly extended that to the copy constructor as well.

Only the compiler-generated special member functions remain (with no
other overloads), and yes, "uuid id;" will be uninitialized.

>> ...
>> I don't think that serialization to and from strings
>> belongs in the type, and it seems like using a lexical_cast is
>> perfectly reasonable:
>
> Yes, taking out the conversions to/from string certainly make the UUID-related code/interface cleaner. More so, IMHO lexical_cast has become somewhat idiomatic for that kind of tasks and provides the well-defined and well-known path to enable the functionality. Much preferred.
>

Glad you agree.

>> ...
>> I don't know if it's useful, but aggregate syntax also opens
>> possibilities:
>>
>>    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.

If people want to define UUID constants, it's one of the nicer ways to do so.

> I see nil() introduced in the code with "As named in RFC 4112, 4.1.7" comment. I tried googling for "RFC 4112" and it gave me "RFC4112 - Electronic Commerce Modeling Language (ECML) Version" with no "nil" mentioned. I have no issues with "nil" pre se as it's well-entrenched in other languages. However, I feel that C/C++ settled on "null" (and C++ 0x introduces nullptr). So, I fail to see any reasons to deviate from that.
>

Sorry, typo on my part.  I've updated the zip.

It should have referred to RFC 4122:

4.1.7.  Nil UUID

   The nil UUID is special form of UUID that is specified to have all
   128 bits set to zero.

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.

Really, I'd be plenty happy to get rid of it entirely, since value
initialization provides the same functionality: uuid id = uuid();

>>> ... the rest snipped.
>
> I see a lot of code cleanup, reorganization and reshuffling. Everything has its place and time. Even though I agree that at some point it needs to be done, I do not feel we've reached that point. I'd much prefer to focus on providing well-thought-through interface. Without having agreed on the interface and settling on what and how certain functionality is delivered to the user I feel that "implementation-detail" discussions seem premature and in fact distracting at this point.
>

I'd argue that some of the reshuffling is an interface issue, as no
generator class had previously been provided for name-based UUID
generation.  Mentioned, yes, but not explicitly detailed.

The implementation detail parts I agree are not of general interest,
but they are likely desirable regardless of eventual interface (since
Andy's code seems solid, and will just be moved around for whatever
interface), and I don't have a better place to mention them.

Thanks for the comments,
~ Scott