Re: [Boost-users] [random] Singleton engine

On Aug 4, 1:39 am, "Diederick C. Niehorster" wrote:

Hi Kevin, others, 2) generator is seeded upon construction. Once seeded, for further calls to the generator instance providing a seed, that seed should be ignored/the generator should not be reseeded. This is what my code currently does

The big question is whether you need the ability to set the seed when you construct it or can you stick with casting the time() or equivalent. As far as I can tell, most singleton libraries instantiate the object on the first use. If you need the ability to set the seed initially, you may need the ability to reseed.

3) Right now, i do not forsee the need of generating random numbers before main has been called. However, I am interested in knowing what the problem would be in trying to use my class before main has been called, I have never dealt with such problems and would appreciate a kick in the right direction so I can learn something about it.

I haven't had this problem, the singleton seems to create itself on first use.

4) will not be used in multithreaded environment. If it ever would be, I would like all threads to use the same generator instance. Is that what will happen now? (I know I would then also have to worry about race conditions, but lets not get into that now).

Right now there is no thread concurrency in my implementation. It is possible that the random number generators themselves are thread-safe, but who knows. If this isn't a problem, then you may be able to do this.

On Wed, Jul 29, 2009 at 3:17 PM, Kevin Martin wrote:

...

I still don't see what your CRandom class offers over creating a variate_generator and putting it in a boost::function, if you are not familiar with the function library you should look it up, it's brilliant.

For me, the generator packages up a bunch of functionality, allows reseeding, and could be used with thread local storage once I figure that out. This is definitely a more complicated use case, so you might be right that it is overkill for this situation. Regardless, whether you have a boost::function or just the variate_generator, I am not sure how this helps the singleton problem. You can have a global variable that contains the variate generator, or the function object, but it still means either a singleton or a global. And you need to be careful with the ODR if you have multiple cpp files.

I have looked it up, thank you for the suggestion. I, however do not see the advantage of wrapping the generator. Also, how does your approach assure that the same engine is always used and that this enigine is never destructed once constructed before program end (i see you are using a shared pointer, I assume it would destruct the engine when all references went out of scope)? I now have a compact class that also ensures i cannot forget to seed my engine as that is done in the constructor.

The singleton libraries properly destruct on program exit, and if shared pointers are used, then the variates themselves will be destructed. If there is a chance that the singleton could be destroyed (or there are dependencies in singletons where destroying in the wrong order causes havoc), I know that Loki has phoenix singletons and other features I have never used.