On 12/28/14 04:09, John Maddock wrote:
Going back to the original code rather than the reduced case, the final int_<3> implies that the first template argument (number<cpp_dec_float<50u> in this case) is convertible to const char* - and that should definitely *not* be the case. To put it another way, the error message could be a lot better (maybe I'll add a static assert for this special case), but the ambiguity is justified because:
is_convertible<number<cpp_dec_float<50u> >, const char*>::value
should never be true, and if it is, the code genuinely doesn't know what to do. So is there a compiler bug effecting is_convertible? Do the type_traits tests pass?
Thank you John, You got it right, and indeed there is compiler bug for libs/type_traits/test/is_convertible_test.cpp As I may see from type_traits logfile that test got 3 separate run-time miscompares: is_convertible_test.cpp:113: The expression: "(::boost::is_convertible<const int *, int*>::value)" had an invalid value (found 1, expected 0) is_convertible_test.cpp:114: The expression: "(::boost::is_convertible<const int&, int&>::value)" had an invalid value (found 1, expected 0) is_convertible_test.cpp:131: The expression: "(::boost::is_convertible<const int[2], int*>::value)" had an invalid value (found 1, expected 0) I cooked 90 lines independent executable test case for those miscomares, and our c++ developers quickly reduced it to 10 lines executable. So, hopefully the problem will be fixed soon. But could you also clarify one more thing for me. Assuming that problem will be fixed, and is_convertible will start to work properly, how that will affect and original issue? Or put in another way, do you think that code below from libs/multiprecision/test/test_mixed_float.cpp is correct? int main() { using namespace boost::multiprecision; test<cpp_dec_float_50, cpp_dec_float_100>(); ... And if this is the case, then how in you opinion compiler should deal with it? Thanks, Sergey