I've no idea frankly *why* the compiler finds those types, but it certainly does do so - please take a look at the reduced test case in the bug report.
Your example builds fine with gcc 4.7.2 and VS 10 on my windows box. Gennadiy
Hi folks, I looked into this one more deeply, and quite honestly, it's got me really confused. I can confirm Gennadiy's result for GCC. But there's more... Let me please try to provide you with additional hard data. My environment: I am building with respect to trunk. My compilers: I am using GCC, and two versions of VC. There is a test case below. The compile and execution results are: * OK for GCC 4.7.2 * Errors for VC10 (ambiguous symbols), AKA VisualStudio 2010 * Errors for VC11 (ambiguous symbols), AKA VisualStudio 2012 Gennadiy, could you please try to reproduce these compilation results in the *trunk* with *the test case below*? Sincerely, Chris. -------------------------------------------------------------------------- #include <boost/multiprecision/cpp_dec_float.hpp> #define BOOST_TEST_MAIN #include <boost/test/included/unit_test.hpp> // Boost.Test #include <boost/test/floating_point_comparison.hpp> typedef boost::multiprecision::number<boost::multiprecision::cpp_dec_float<50>, boost::multiprecision::et_off> cpp_dec_float_50_noet; BOOST_AUTO_TEST_CASE(sqrt_test) { static const cpp_dec_float_50_noet tolerance = std::numeric_limits<cpp_dec_float_50_noet>::epsilon() * 100; BOOST_CHECK_CLOSE_FRACTION(sqrt(cpp_dec_float_50_noet(2)), cpp_dec_float_50_noet("1.41421356237309504880168872420969807856967187537694807317668"), tolerance); }