Re: [boost] [Boost-announce] [SPAM:## 74%] [Review] The review of the Boost.Guid library starts today (April 30th)

From: Jake Voytko (jakevoytko_at_[hidden])
Date: 2007-05-09 13:11:12

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_at_[hidden]> 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_at_[hidden]    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
>
>