Subject: Re: [boost] [UUID] Code for UUIDs as PODs and other changes
From: Roman Yakovenko (roman.yakovenko_at_[hidden])
Date: 2008-12-06 14:48:26
On Sat, Dec 6, 2008 at 9:40 PM, Scott McMurray <me22.ca+boost_at_[hidden]> wrote:
> On Sat, Dec 6, 2008 at 14:07, Roman Yakovenko <roman.yakovenko_at_[hidden]> wrote:
>> On Sat, Dec 6, 2008 at 11:10 AM, Scott McMurray <me22.ca+boost_at_[hidden]> wrote:
>>> I remarked the other day that a UUID has a well-defined, portable
>>> binary format, so I took a bit of time to rearrange things to make the
>>> UUID class a POD and make more use of the generators idea. Along the
>>> way I made a few other changes.
>>> I've uploaded the result (with updated docs) to the vault as
>>> uuid_alt_v13_pod.zip :
>>> Some elaboration follows below. Comments appreciated.
>> Hi. Very nice implementation. I have few question:
> Thanks, though most of the implementation credit still goes to Andy.
>> 1. Why variant() and version() are member function of class uuid? I
>> think they should be free functions.
> Either way would work, obviously. I thought of them as properties of
> the UUID, rather than some computed thing, but that's an iffy
> difference, so for normal encapsulation justifications it may better
> to make them non-member.
>> 2. May be it is better to introduce "native_generator" which is cross platform?
> There is actually a typedef for that. I figured that it would be
> better to keep the implementations separate and conditionally compile
> the typedef, rather than try to mix the 2 (or more, if other
> platforms) implementations into one.
> That said, strategies would also work nicely for that, and would allow
> cross-platform specification of which UUID version you'd like, too...
Sorry for noise. I didn't see "native_generator" typedef "on Windows".
May be it worth to introduce "native_generator.hpp" header, which will
select the platform and "include" the native generator?
-- Roman Yakovenko C++ Python language binding http://www.language-binding.net/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk