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

Subject: Re: [Boost-users] [Review] UUID library (mini-)review starts today, November 23rd
From: Scott McMurray (me22.ca+boost_at_[hidden])
Date: 2008-12-03 15:57:45

On Wed, Dec 3, 2008 at 15:19, muhammadchang <kennethlaskoski_at_[hidden]> wrote:
>
>>"behaves and cost, exactly the same as any built in type" and the
>>"default constructor [...] generates a valid random uuid" seem rather
>>opposed.  int() is not a random int, it's 0.  No fundamental type --
>>no standard library type either, that I can think of -- has T() !=
>>T(), yet you want uuid() != uuid().
>
> You are right, there is an apparent contradiction in my wording above. By
> "behaves and cost", I mean implementing comparison operators, inserters and
> extractors, for example. Where applicable, of course, and with minimum
> overhead. But an UUID is more than its bare 128-bit representation. IMHO,
> what justifies the truly exceptional uuid() != uuid() is the "unique" in
> "universally unique id".
>

But it's the mapping of the ID to something that's unique, not the
objects themselves.  The only time you can do something useful with a
UUID is when you have two that are the same, so I still don't think
breaking normal semantics is justified.

The usage I was looking at for my project never needs the UUID library
to generate one itself, in fact.  They're all generated in the
database (http://dev.mysql.com/doc/refman/5.0/en/miscellaneous-functions.html#function_uuid),
but the class is still useful for parsing and serialization.

Changing tacks somewhat...

I was just looking deeper into the implementation, and saw some things
that worry me.  For example, this looks like an aliasing violation in
uuid.hpp line 279:

    *reinterpret_cast<unsigned long*>(&data[i]) = _v_gen();

It's at least clearly byte-order-dependant, which isn't good, since
I'd expect a generator seeded the same way to always produce the same
UUIDs, regardless of architecture.

I'm pleased to see proper shifting and masking in the SHA1 code, which
made me think of something: Why not just make the UUID class a PoD?
It has an architecture-independent in-memory format (rfc4122, section
4.1.2, which is already followed), so turning it into one would be
straight-forward, and would allow it to be very easily & safely
splatted to and from files.

This would require moving the constructors and such to generators,
stream operators, and similar, but I think those are positive changes
in any case.  It certainly solves the "what should the constructor do"
problem, and places all the various generators (nil, random, name,
time, ...) at equal footing.

It's a value type, so let's make it as much like an int as possible.