Remove using std::cbrt to fix build on platforms which don't support it. #888
Conversation
|
@mborland : Could you review/merge? |
| @@ -1011,7 +1011,6 @@ template <class T> | |||
| template<int N> | |||
| inline T constant_plastic<T>::compute(BOOST_MATH_EXPLICIT_TEMPLATE_TYPE_SPEC((std::integral_constant<int, N>))) | |||
| { | |||
| using std::cbrt; | |||
| using std::sqrt; | |||
| return (cbrt(9-sqrt(T(69))) + cbrt(9+sqrt(T(69))))/cbrt(T(18)); | |||
There was a problem hiding this comment.
If the target platform standard library is missing cbrt entirely will this change the behavior?
There was a problem hiding this comment.
We should only be in the calculate_constants.hpp file if the type T is wider than the precision of long double; so no behavior should be changed. This was the observation of @jzmaddock .
There was a problem hiding this comment.
Sorry, I mean't won't the parser hit the call to cbrt and fail instead of failing at using std::cbrt? I doubt uClibc++ would be able to compile Boost.MP so I am not sure why this would be instantiated either way.
There was a problem hiding this comment.
Wait . . . if it can't compile boost/multiprecision then shouldn't it have died much earlier in the chain?
Ultimately I think you're right: This needs to be tested by the bug reporter.
There was a problem hiding this comment.
Ultimately I think this is going to boil down to a standard library compliance problem. We are moving to C++14 in the next release so I don't think it's worth trying to make this work for a implementation that does not even fully support C++11.
No, the call is dependent upon the type of the template parameter, so it will do ADL when/only if instantiated, and since this code is for UDT's only, there had better be a cbrt in the same namespace as the type. In other words this change does no harm. |
No description provided.