On Thu, Dec 18, 2008 at 13:37, Andy Tompkins <atompkins@fastmail.fm> wrote:
Your right! Hmm. I want to be able to use lexical_cast as above, but I also don't want a default constructor. I think I will optionally include/exclude the default constructor with a #define. And I think a more explicit way to convert a string representation of a uuid to a uuid should be included. Something like the following:
template <typename ch, typename char_traits, typename allocator> uuid from_string(std::basic_string<ch, char_traits, allocator> const& s); uuid from_string(const char* name); uuid from_string(const wchar_t* name);
As far as I'm concerned, the "explicit way to convert a string representation of a uuid to a uuid" is spelled lexical_cast<uuid>. I really dislike the idea of some idiom that's not used anywhere else.
class string_generator //not a good name {
I have to say, this seems really silly.
// valid expression // generator() - result type must be convertible to a uuid template <typename Generator> explicit uuid(Generator & generator);
Does this use the Concept defined at the end?
Yes.
What's the result_type needed for? It seems strange to not allow a uuid(*)() to be a UUIDGenerator. Perhaps you can say "where result_type is some unspecified type with an implicit conversion to uuid", not not require it as a typedef? Though I'm still not convinced that the constructor is worth bothering with.
On the assumption that an MD5 version would be a reasonable extension, what about templating this on the hasher, defaulting to the sha1 one?
That way both the defaults would have the <>, for consistency (random_generator<> and name_based_generator<>).
Good idea. But there is no md5 implementation in boost, and I'm not planning to write one (unless there is significant demand).
I wouldn't expect you too, but I can foresee a boost.message_hash library in the future, at which point it ought to be simple to make a name_based_generator<md5>. Would be a reasonable thing for someone else to contribute, too, if they needed it.
Good point. Maybe just random_based_generator and version_random_based.
Still a touch long-winded, but I can't think of anything better.
This function will treat the stream a sequence of bytes and will have the same effect as using the ByteInputIterator version on the stream. So each wchar_t will be treated as sizeof(wchar_t) bytes.
I think that should be up to the user. Otherwise endianness and wchar_t size differences mean it's not going to generate consistent UUIDs (such as between window's UCS-2 wchar_t and linux's UTF-32, iirc). I think it'd be better to force the user to choose between casting to char*, converting to UTF-8, using a casting_iterator, or whatever other method they like, and just allowing the 1-byte versions.
Would it worth be adding one for message UUID generators too?
What do you mean by message uuid generators?
Name-Based (Oor maybe Consistent) UUID Generator constructor: Generator(uuid uuid_namespace) creation: result_type operator(ByteIteratorRange) creation: result_type operator(ByteIterator begin, ByteIterator end) ... or something like that.