Re: [Boost-users] [Review] UUID library (mini-)review starts today, November 23rd

Subject: Re: [Boost-users] [Review] UUID library (mini-)review starts today, November 23rd
From: Christian Holmquist (c.holmquist_at_[hidden])
Date: 2008-12-02 18:26:13

2008/12/2 Andy Tompkins <atompkins_at_[hidden]>

> > size_type size() The underlying container is boost::array, shouldn't
> > this function be made static? Or is the size of the uuid
> > implementation defined and the user shouldn't count on it's length?
>
> It could easily be made static.  It will _always_ return 16.

I think that should be part of the documented interface. It's just a matter
of not confusing the reader that the uuid may be of variable length.

>
>
> > is_null() What does this mean? Ah, ok, from the docs I see it's
> > a magic uuid (all zero) that is_null. Maybe is_zero() would be
> > more clear?
>
> Maybe.  Maybe uninitialized, nil.  I don't think it matters too
> much because I don't think there is a name that everyone will think
> is obvious.

You're probably right.

> > Maybe this is out of the question to most, but is the uuid class
> > needed at all? I'd be happy to see the following working (cause then I
> > can use our own uuid class with the algorithms provided by the
> > library).
> >
> > #include <boost/uuid/random_generator.hpp>
> > #include <boost/uuid/support/array.hpp>
> > #include <boost/uuid/io.hpp>
> >
> > typedef boost::array<char, 16> id_type;
> > boost::uuid::random_generator<id_type, boost::mt19937> uuid_gen(...);
> > my_id id = uuid_gen();
> > std::cout << boost::uuid::format(id) <<std::endl;
>
> I not keen on this.  The fact that boost::uuid is implemented with
> boost::array is just an implementation detail.  That may change.  I
> want the public interface to remain the same.

Ok.
For the sake of interface, does it make sense to you adding

const char* uuid::data() const
and
static std::size_t uuid::size()

that you won't change in future releases?

I think it's an important feature for a uuid to store its 128bit value as a
continues range of bytes, and that users can rely on using it as such where
needed. Also, that the ordering of the bytes won't change in future
releases. Uuids are likely to be persistent somewhere, and not necessarily
trough the means of boost.serialization where version data can be attached.

Regards,
Christian