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

Subject: Re: [boost] [UUID] Code for UUIDs as PODs and other changes
From: Vladimir Batov (batov_at_[hidden])
Date: 2008-12-06 19:49:04

> PODness:

I am personally far from thrilled and fail to see benefits of that move.

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

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

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

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.

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

Best,
Vladimir.