On Wed, Dec 3, 2008 at 15:19, muhammadchang
"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