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

I see, our use cases are radically different. You ain't talking about objects at all. If all you need is a PoD, why not just declare typedef boost::array uuid;//? Inter, Kenneth Scott McMurray-2 wrote:

On Wed, Dec 3, 2008 at 15:19, muhammadchang 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...), 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(&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. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

-- View this message in context: http://www.nabble.com/-Review--UUID-library-%28mini-%29review-starts-today%2... Sent from the Boost - Users mailing list archive at Nabble.com.