Re: [Boost-users] [Boost-announce] [Review] UUID library (mini-)review starts today, November 23rd

On Dec 9, 2008, at 12:17 PM, Andy Tompkins wrote:

On Tue, 9 Dec 2008 03:34:01 -0500, "Daryle Walker" said:

...

[SNIP]

...

Is default construction useful besides when initialization can't be done in one step? Instead of an "is_null" member function, maybe (pseudo- )Boolean conversion (and "operator not") can be used.

The default constructor is unintuitive. I will likely remove it. I will add a 'boolean' conversion and possibility operator!.

...

I don't think the multitude of string conversion techniques are needed. Keep the constructor with "char const *" for pseudo- literals. Everything else, in either direction, could use "lexical_cast".

I agree, lexical_cast is good. I will remove the to_..._string functions. The constructor that takes a string will likely move to a generator. [SNIP]

So, there won't be any constructors besides the constructor template that takes an input iterator for sixteen octet reads (and an implicit copy constructor)? You could make UUID a POD type if you could move that constructor too. (It could probably be moved to a creation function, done as a static member function for UUID. The Nil-UUID can be implemented this way too.)

...

Should the serialization be done in a separate header? BTW, how is a custom primitive type handled? Is it just a byte-level save/load of memory? (What if the type isn't POD, like this one?)

Yes, it is a byte-level save/load. My reason was so that exactly 128 bytes are saved/loaded.

[TRUNCATE] You mean 128 bits, or 16 octets. An alternative I used, for a MD5 bit-queue, was to group the bits into sextets (6-packs), map that to a base-64 string, and serialize that string. For 128 bits, you get 21 sextets and 2 remaining bits, for a string of 22 characters. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com