Subject: Re: [boost] [uuid] Interface
From: Scott McMurray (me22.ca+boost_at_[hidden])
Date: 2008-12-18 20:51:54
On Thu, Dec 18, 2008 at 13:37, Andy Tompkins <atompkins_at_[hidden]> 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&
> 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?
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
> 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,
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk