Re: [boost] [uuid] Interface

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&
> 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.