Re: [boost] [review] Boost.Guid

From: Johan Nilsson (r.johan.nilsson_at_[hidden])
Date: 2007-05-08 02:23:50

Andy wrote:
> "Peter Dimov" <pdimov_at_[hidden]> wrote in
> news:002e01c790c0$0f2d3510$6407a80a_at_pdimov2:
>
>> Andy wrote:
>>
>>> I agree that the create function needs improvement.  It suffers from
>>> threading problems (because of static variables) and from a hard
>>> coded random number generator (also a hard coded seed).
>>>
>>> My solution is to create a generator class, as follows:
>>>
>>> // maybe a better name
>>> // maybe a different default random number generator
>>> template <typename UniformRandomNumberGenerator = boost::mt19937>
>>> class random_guid_generator : boost::noncopyable
>>
>> [...]
>>
>>> random_guid_generator<> guid_gen;
>>> guid g = guid_gen.create();
>>
>> Why not just add an Engine & e parameter to guid::create?
>
> Good idea.  Something like:
>
> template<typename Engine>
> boost::guid guid::create(Engine& e = boost::mt19937(get_seed()));

[sorry for jumping in]

That would need to be "Engine const&", right?

>
> where get_seed() does something like what you said below.
>
> I want to be able to call the create function with a default Engine
> because I don't want to force users to create one themselves.

I'd suggest to rather use an overload of create with zero arguments. Helps
if the methods are ever used with function binding.

>  The
> only downside is for people who do want a different engine/seed, they
> will
> have to pass that engine to the function everytime they call it.

Yes, people are likely to go for one specific engine within a specific
context (e.g. application). Perhaps a _complementing_ guid_factory would be
usable for people preferring the generator/factory interface you mentioned
above.

template<typename Engine>
class guid_factory{
...
explicit guid_factory(Engine const& e = Engine())
  : e_(e)
{}

guid create_guid() [const?]
{
    return guid::create(e_);
}
...
[mutable?] Engine e_;
};

/ Johan