On Thu, 11 Sep 2008 22:53:49 +0200, Hartmut Kaiser <hartmut.kaiser@gmail.com> wrote:

...

Any idea what happened to the UUID library? I believe the mini review that was supposed to happen after the library got accepted provisionally never happened, right?

Nope, this never happened because the author (CC'ed) never got back to it. It's a pity that Andy dropped the ball and disappeared after being 99.9% through the review of his library.

OTOH it's perhaps better he disappeared _before_ pushing the library into Boost...

I think anybody interested in taking ownership of this library and going the last step is highly welcome in doing so. I don't expect Andy to object.

Hartmut, do you have a link or can you describe what this last step is? I typically don't have time to create libraries from scratch. Having taken over Boost.Process already and trying to get it done I might specialize on Boost libraries though whose development was abandoned. :) Boris

On Sat, 13 Sep 2008 19:16:24 +0200, Hartmut Kaiser <hartmut.kaiser@gmail.com> wrote:

[...]IIRC, all what's left to be done is to request a mini-review for the parts criticized during the review. Updating the docs to use the quickbook

I see. Then I should find out what these parts are, check them myself and - if I think they have been fixed the way the reviewers agreed on in May 2007 - request a mini review?

format might be another thing, but this is not mandatory.

The docs are HTML files - or do you know if they have been generated from another format than quickbook? Boris

On Thu, 11 Sep 2008 15:53:49 -0500, "Hartmut Kaiser" <hartmut.kaiser@gmail.com> said:

...

Any idea what happened to the UUID library? I believe the mini review that was supposed to happen after the library got accepted provisionally never happened, right?

Nope, this never happened because the author (CC'ed) never got back to it. It's a pity that Andy dropped the ball and disappeared after being 99.9% through the review of his library.

OTOH it's perhaps better he disappeared _before_ pushing the library into Boost...

I think anybody interested in taking ownership of this library and going the last step is highly welcome in doing so. I don't expect Andy to object.

Regards Hartmut Review Manager

Forgive me the delay, but I would like to submit my library. I realize that I did not communicate sufficiently with you. I apologize for my apparent disinterest, it was unintentional. For the past 16 or so months, I have been essentially working two jobs. As you can imagine, my spare time has become virtually non-existent. Nonetheless, the library is ready for the mini-review, except that I am only able to compile and test it with Visual Studio Express as at the present time I do not have access to a different compiler. I have uploaded uuid_v11.zip to the Boost Vault. Will someone compile it for me with a different compiler/platform? If so, and if the library compiles, then I request the mini-review of the uuid library. Andy

Since UUIDs are generally used to identify resources, it could be that someone wants to instantiate Boost.Unordered with UUID. I don't know exectly what are the requirements for the type parameter of Boost.Unorder, but I hope that most of them are yet met by UUID. Surely it is necessary to extend Boost.Hash, but according to < http://www.boost.org/doc/libs/1_36_0/doc/html/hash/custom.html> this can be done defining a free function without any explicit coupling with Boost.Unordered/Hash. Summarizing the support for Boost.Hash/Unorded should be a zero-cost addition which should't cause the inclusion of no headers from those libraries. Best regards, Manuel Fiorelli

I don't feel qualified to evaluate your hash function. However, it seems to me that your code is the same as boost::hash_combine, thus it should be good. In the statement for(uuid::const_iterator i=u.begin(); i != u.end(); ++u) you should increment i. Best regards Manuel Fiorelli

I looked at the implementation of the constructor which takes the byte array. I found that the sequence is used as a byte sequence. Indeed, in the last line of the paragraph you state that the range must span at least 16 elements, but in the first lines you write assert(a.size() == 32); which suggested to me that there were 32 elements in the sequence. I think that it is a typo.... Regards Manuel Fiorelli

Hi, On Sat, 20 Sep 2008 04:35:44 +0200, "Manuel Fiorelli" <manuel.fiorelli@gmail.com> said:

According to the documentation, UUIDs can be constructed either from a string or a byte array. In my opinion the term "byte array" could lead to misinterpretation since, in my understanding, the constructor expects a sequence of characters representing the HEX digits not a sequence of bytes: indeed, the sequence has 32 elements (32x4=128) and not 16 (16x8=128).

This is a typo in the docs. The array of bytes needs to have a size at least 16, not 32.

Also, when you state that every function is thread-safe, do you mean that several threads can work simultaneously on different instances? I am not sure if this is thread-safety or reentrancy.

I know that there isn't an universally accepted definition, but at lest there should be one accepted by all Boost developers.

I saw that in the documentation of an older version of Boost.Thread there was a glossary < http://www.boost.org/doc/libs/1_34_0/doc/html/thread.html#thread.glossary> where there is the definition of thread-safe program, but it seems that the glossary was removed by the newer documentation < http://www.boost.org/doc/libs/1_36_0/doc/html/thread.html>.

In my opinion there should be, for example in Boost.Thread, a definition of terms such as thread-safe, reentrant (class, function), so that when an author uses them can add a link to the corresponding paragraph in order to avoid misunderstanding.

Best regards, Manuel Fiorelli

What I mean is that all classes are as thread-safe as an int. Any all free functions are reentrant. Does this answer your question? Andy.

Hi, On Mon, 22 Sep 2008 10:42:55 +0200, "Manuel Fiorelli" <manuel.fiorelli@gmail.com> said:

Hi, I saw that you don't serialize accesses to member data, so I wouldn't call your class thread-safe but reentrant, since it can be safely instantiated in several concurrent threads, which shouldn't however share the same instance.

I agree, an instance can not be shared between threads without proper external synchronization.

Maybe I have a wrong idea of what a thread safe class should be....

I use the definitions from Qt: < http://doc.trolltech.com/4.1/threads.html#reentrancy-and-thread-safety>

I think that UUID doesn't need synchronization, but it is important that reading the documentation the user cannot misunderstanding the library guarantees against multi-threading.

I agree. I will modify the documentation to reflect this.

I run on my Linux box (equipped with gcc (GCC) 4.3.0) the tests "test_uuid.cpp" and "test_sha1.cpp" which pass. I didn't run the "test_serialization.cpp" since I use a prepackaged version of boost.

Obiuvsly, I run the tests against the source with the modifcations I posted on this mailing list.

Best regards, Manuel Fiorelli

Thanks, Andy Tompkins

On Thu, 18 Sep 2008 00:42:42 +0200, "Manuel Fiorelli" <manuel.fiorelli@gmail.com> said:

Hello, I have some notes about docs and implementations.

In the examples you use the class std:vector without any parameter (may be char?).

Yes, they should be std::vector<char>

Looking at the code, in the file seed_rng.hpp: you should add the following includes #include <cstring> // where std:memcpy is declared #include <boost/generator_iterator.hpp> // where boost:generator is defined

Yes, both includes should be there.

in the file uuid.hpp: at line 259 you should add typename in front of helper_type::value_type

I believe so.

I would appreciate if you could let me know if you find this notes correct or if I was missing something.

Best regards, Manuel Fiorelli

Thank you very much. Andy Tompkins