Re: [boost] [UUID] Code for UUIDs as PODs and other changes
On Sat, Dec 6, 2008 at 14:07, Roman Yakovenko <roman.yakovenko@gmail.com> wrote:
On Sat, Dec 6, 2008 at 11:10 AM, Scott McMurray <me22.ca+boost@gmail.com> 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 : http://www.boostpro.com/vault/index.php?action=downloadfile&filename=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...
On Sat, Dec 6, 2008 at 9:40 PM, Scott McMurray <me22.ca+boost@gmail.com> wrote:
On Sat, Dec 6, 2008 at 14:07, Roman Yakovenko <roman.yakovenko@gmail.com> wrote:
On Sat, Dec 6, 2008 at 11:10 AM, Scott McMurray <me22.ca+boost@gmail.com> 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 : http://www.boostpro.com/vault/index.php?action=downloadfile&filename=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/
On Sat, Dec 6, 2008 at 14:48, Roman Yakovenko <roman.yakovenko@gmail.com> wrote:
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?
No, the noise was a good thing. I think I like the native_generator better, in retrospect. I'm thinking of something like this (with the details better flushed out): #ifdef BOOST_HAS_E2FSPROGS #include <uuid/uuid.h> struct native_default { void generate(uuiid &u) { uuid_generate(&*u.begin()); } }; struct native_time_based { void generate(uuiid &u) { uuid_generate_time(&*u.begin()); } }; struct native_random { void generate(uuiid &u) { uuid_generate_random(&*u.begin()); } }; #elif BOOST_HAS_WINDOWS #include <rpc.h> struct native_default { void generate(uuiid &u) { UUID u_; UuidCreate(&u_); u.assign((uint8_t*)&u_, 16+(uint8_t*)&u_); } }; // And others, possibly #endif template <typename NativeStrategy = native_default> struct native_generator : NativeStrategy { uuid operator()() const { uuid u; NativeStrategy::generate(u); return u; } }; Looks like less code duplication overall, too. With SFINAE it should even work for SHA1 and MD5 generators, with an overloaded constructor to pass a uuid to the Strategy's constructor, and an overloaded operator() that takes a message to hash. The one problem is if people wanted more choice. I was thinking that the http://www.ossp.org/pkg/lib/uuid/ could provide another generator in the old scheme, but that may also just be a waste of effort, since it's less common than the e2fsprogs libs. Also, what it provides are the same things that Boost.UUID provides natively, so... ~ Scott
participants (2)
-
Roman Yakovenko -
Scott McMurray