On Jul 28, 8:14 pm, "Diederick C. Niehorster"
Hi Kevin,
Thank you for your suggestions, I have learned from your code but don't think it is optimally suited for my needs. In general, wouldn't it be a good idea to have a singleton library inside boost? To my understanding they are used quite often, so better provide the world with a (few) good implementation(s suited for different needs). What do you think?
I ended up using the Loki singleton for the exact same purpose... though I am happy to change for a more flexible implementation. For those who are wondering the use case: When you have a library doing a great deal of montecarlo, you can't keep recreating the generators in sub-functions. For example, you want to be able to easily draw uniforms all over your library without passing around a generator every time from the library user code. Also, you sometimes need to start with the same seed value for regression testing across a variety of functions. Here is a link to my implementation (apologies for bad style and mistakes, I wrote a lot of it before people in this group started teaching me C++ and generic programming. And thanks again to everyone for your help over the last year). http://econtoolkit.com/browser/libraries/trunk/etk/etk/math/random/random.hp... This is also wrapping the Intel MKL VSL for streams of multivariate normals. See http://econtoolkit.com/browser/libraries/trunk/etk/etk/math/distributions/mu... for how that part of the singleton is used in the draw() function. The problem I have with my implementation is that what I really want is a thread-local singleton. If I have to make the access threadsafe, then I may be better off recreating it every time. Any ideas on how best to do this? Could it be done with the boost::serialization singleton? My guess is that it may be possible by using the loki creation policy, but I have no idea how to go about doing it.