I think that's looking OK for threads.
Actually no, that code *on it's own* is most definitely not thread safe. Anywhere you have a function scope: static const UDT my_object. where UDT is not a POD, then initialization of my_object is subject to race conditions (in C++03 anyway, C++11 and recent GCC versions get this right I believe). What's more if you try to fix the race condition using the "double checked looking idiom", it's still not thread safe, you actually do have to grab a mutex with every call to the function :-(
However, there's a trick I stole from Boost.Pool employed here, in the:
constant_initializer<T, &get_constant_e<T> >::do_nothing();
<snip> Thanks, John. That constant_initializer sure is a nice programming element. So, let me get this straight. The instantiation of a template such as get_constant_ln2() causes the compiler to notice that it needs to instantiate one (and only one) instantiation of template "long_type"::init in the first translation unit in which it is encountered. C++ has a one-time deal for template instantiation of non-local class-type statics, and the thing ends up being initialized once with ctor code in the pre-main() initialization. Is that what you are talking about? OK. But finally, what if we bombard get_constant_ln2() with an MP type of run-time dynamic precision, first with 100 decimal digits, then with 200 decimal digits? Who tells get_constant_ln2() that it needs to re-calculate ln2? Or is this just a matter of documentation, saying, in effect, "don't do this!". Best regards, Chris.