Andy wrote:
"Peter Dimov" <pdimov@mmltd.net> wrote in news:002e01c790c0$0f2d3510$6407a80a@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