2008/12/2 Andy Tompkins
<atompkins@fastmail.fm>
> 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;
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