I implemented this but it seems to add limitations on the
types usable. They now require to have an overloaded istream extraction operator and a specialization of std::numeric_limits. Those two limitations are reasonable but I am not certain that we want to impose such conditions on the template types.
The requirements are more subtle than that, the logic goes something like this:
* If there's a numeric_limits specialization: * If the precision is less than a float/double/long double, and T is constructible from those types, then construct from float/double/long double. * If the precision is < 100 decimal places: * If T is constructible from a const char* then construct the constant that way. * Use the iostream operator to stream the constant in (we could arguably use a trait to check whether this is supported before using it as well). * Precision > 100 digits - calculate the constant and cache the result. * No numeric_limits - use boost::math::tools::digits<T>() to check runtime precision and pick either construct-from string or calculate the constant.
There's also a trait class that can be specialized for some type T to override the above logic. So you don't have to have either numeric_limits or an iostream operator, but you have to have *something* that allows us to get the constant in there. HTH, John.
Thank you, John. @Matthieu: But I believe that this refinement of boost::math::constants is only available in the trunk. So if you would like to take advantage of this policy on mathematical constants, you have to test your <boost/math/complex/complex.hpp> with-respect-to the trunk. Otherwise, you need to make a workaround via providing your own template specializations of pi(), ln2(), ln_10() for now. This is what I did in my code from yesterday for my fixed-point class. Best regards, Chris.