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: muhammadchang (kennethlaskoski_at_[hidden])
Date: 2008-12-05 21:07:39

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<uint8_t, 16> uuid;//?

Inter,
Kenneth

Scott McMurray-2 wrote:
> 
> 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.
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> 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%2C-November-23rd-tp20652849p20865931.html
Sent from the Boost - Users mailing list archive at Nabble.com.