6 Dec 20:44
Re: [Review] UUID library (mini-)review starts today, November 23rd
Andy Tompkins <atompkins <at> fastmail.fm>
2008-12-06 19:44:11 GMT
2008-12-06 19:44:11 GMT
On Tue, 2 Dec 2008 17:26:13 -0600, "Christian Holmquist" <c.holmquist <at> gmail.com> said: > 2008/12/2 Andy Tompkins <atompkins <at> 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. I will document this. < snip > > > > 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? Hmm, I'm not sure. There is another post that I haven't got to replying to that talks about platforms with different sized types (char, int, ...). If I make sure that sizeof(boost::uuids::uuid) == 16 bytes on every platform then some platforms may get a performance penalty. On a platform where sizeof(char) != 1 or sizeof(int) != 4 then boost::uuids::uuid will have to do more work to put bits where they belong. Then again, I don't think I can actually guarantee on every platform that sizeof(boost::uuids::uuid) == 16. What I have done is make sure that each of the 16 blocks of bits in a boost::uuids::uuid is at least 8 bits. Thus boost::uuids::uuid::begin() and boost::uuids::uuid::end() will walk the 16 blocks correctly. I know this didn't really answer your question. I would like to offer const char* uuid::data() const, but I'm not sure that I can. > 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. I agree. I did provide begin() and end() with this purpose in mind. And the order will never change. > Regards, Christian Regards, Andy Tompkins
RSS Feed