Re: [boost] [Boost-announce] [SPAM:## 74%] [Review] The review of the Boost.Guid library starts today (April 30th)
hi all, first i need to say, i have been using the guid library in my computer music system 'nova' for quite some time now, and several core parts heavily rely on it.
- What is your evaluation of the design?
the guid class is very easy to use and provides everything, that i needed for my application ... the only problems that i see, is the blocking implementation of guid::create() in order to use it in largely multithreaded environments, i would like to see an implementation with thread-local storage for the random number generator instead of a single one, guarded by a mutex...
- What is your evaluation of the implementation?
from my point of view, it looks quite well-written. as it's a header-only library, it's very straight-forward to use ...
- What is your evaluation of the potential usefulness of the library?
when looking for a uuid implementation, i didn't find another implementation, that's that portable to other platforms ...
- Did you try to use the library? With what compiler? Did you have any problems?
as stated above, i've been using the library for quite some time now. it's successfully running under gcc-4.0 on osx and >=gcc-4.1 on linux. however, i'm not sure about the naming of the library, whether it should be called 'uuid' or 'guid'. afaik 'guid' is the term used for the m$ implementation of the uuid iso standard, which is the reason, why i would be in favor of the term 'uuid' i would like to see the guid libary as part of boost. nevertheless, i'll continue to use the guid class, whether it is part of boost or not. cheers, tim -- tim@klingt.org ICQ: 96771783 http://tim.klingt.org Question: Then what is the purpose of this "experimental" music? Answer: No purposes. Sounds. John Cage
Short answer: Accept, so long as issues with the create() function are worked out. - What is your evaluation of the design? I feel that the user interface is very intuitive, and one could quickly incorporate a user ID into their program with minimum hassle - What is your evaluation of the implementation? Upon quick perusal, I didn't find anything blatantly wrong. - What is your evaluation of the documentation? I felt that for such a minimal library, I had to dig too much for the first usable code example, which is generally the first thing I look for when using a new library. - What is your evaluation of the potential usefulness of the library? In environments where only a single machine generates the IDs, it is extremely useful. However, as others have mentioned, in guid::create(), seeding the random number generator with time(0) certainly negates the primary reason to use GUIDs at all, as in a multiple machine environment it's no longer possible to guarantee that the IDs are unique. I feel that this contradicts the entire reason I would look for an outside library to generate GUIDs rather than do the legwork towards implementing one myself. The documentation for the library touts concurrency-heavy applications in its rationale section, but it seems concurrency issues would be introduced by time(0) I liked the suggestion of MAC address + time generation, but I don't know how feasible this would be to accomplish in multiple operating systems with the same implementation. Even simpler, the user could have the option of giving the random number generator their own seed. Simply skipping it could stick with time(0), but if they know they could run into concurrency issues, they could provide their own solution. Don't get me wrong, though.. I've spent a lot of time on what I felt was the weak part of the implementation. If the issue with the create() function is worked out, then this library would be incredibly quick and effective, and I myself would certainly use it in the future in all applications that require unique IDs! - Did you try to use the library? With what compiler? Did you have any problems? Yes, using Visual Studio 8.0, and I had no problems. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I devoted an hour and a half to the evaluation - Are you knowledgeable about the problem domain? As a college student, I'm relatively new to issues of truly random generation. I've taken classes where professors have shown weaknesses in random number generators, how to notice them, and how to take advantage of them, but I still consider myself a newbie as far as random numbers go. On 5/2/07, Tim Blechmann <tim@klingt.org> wrote:
hi all,
first i need to say, i have been using the guid library in my computer music system 'nova' for quite some time now, and several core parts heavily rely on it.
- What is your evaluation of the design?
the guid class is very easy to use and provides everything, that i needed for my application ... the only problems that i see, is the blocking implementation of guid::create() in order to use it in largely multithreaded environments, i would like to see an implementation with thread-local storage for the random number generator instead of a single one, guarded by a mutex...
- What is your evaluation of the implementation?
from my point of view, it looks quite well-written. as it's a header-only library, it's very straight-forward to use ...
- What is your evaluation of the potential usefulness of the library?
when looking for a uuid implementation, i didn't find another implementation, that's that portable to other platforms ...
- Did you try to use the library? With what compiler? Did you have any problems?
as stated above, i've been using the library for quite some time now. it's successfully running under gcc-4.0 on osx and >=gcc-4.1 on linux.
however, i'm not sure about the naming of the library, whether it should be called 'uuid' or 'guid'. afaik 'guid' is the term used for the m$ implementation of the uuid iso standard, which is the reason, why i would be in favor of the term 'uuid'
i would like to see the guid libary as part of boost. nevertheless, i'll continue to use the guid class, whether it is part of boost or not.
cheers, tim
-- tim@klingt.org ICQ: 96771783 http://tim.klingt.org
Question: Then what is the purpose of this "experimental" music? Answer: No purposes. Sounds. John Cage
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
"Jake Voytko" <jakevoytko@gmail.com> wrote in news:16c2caba0705091011k7203bc43uf4b71f27dbd196a7@mail.gmail.com:
Short answer: Accept, so long as issues with the create() function are worked out.
< snip >
- What is your evaluation of the documentation? I felt that for such a minimal library, I had to dig too much for the first usable code example, which is generally the first thing I look for when using a new library.
I will create an intro section that shows common uses.
- What is your evaluation of the potential usefulness of the library? In environments where only a single machine generates the IDs, it is extremely useful. However, as others have mentioned, in guid::create(), seeding the random number generator with time(0) certainly negates the primary reason to use GUIDs at all, as in a multiple machine environment it's no longer possible to guarantee that the IDs are unique. I feel that this contradicts the entire reason I would look for an outside library to generate GUIDs rather than do the legwork towards implementing one myself. The documentation for the library touts concurrency-heavy applications in its rationale section, but it seems concurrency issues would be introduced by time(0)
See other posts. This will be fixed by passing a random number generator to the create function.
I liked the suggestion of MAC address + time generation, but I don't know how feasible this would be to accomplish in multiple operating systems with the same implementation. Even simpler, the user could have the option of giving the random number generator their own seed. Simply skipping it could stick with time(0), but if they know they could run into concurrency issues, they could provide their own solution.
< snip > Andy.
participants (3)
-
Andy -
Jake Voytko -
Tim Blechmann