Boost logo

Boost :

Subject: Re: [boost] [uuid] Interface
From: Scott McMurray ([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,

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, gregod at, cpdaniel at, john at