|
Boost : |
Subject: Re: [boost] [multiprecision] [detail] [number_base.hpp] Ambiguous partial specialization for canonical_imp
From: Sergey Sprogis (sergey.sprogis_at_[hidden])
Date: 2014-12-29 14:30:50
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk