![]() |
Home | Libraries | People | FAQ | More |
An artifact of providing C++ standard library support for quadmath may mandate
the inclusion of <boost/cstdfloat.hpp>
before the inclusion of other headers.
Consider a function that calls fabs(x)
and has previously injected std::fabs() into local scope via a using
directive:
template <class T> bool unsigned_compare(T a, T b) { using std::fabs; return fabs(a) == fabs(b); }
In this function, the correct overload of fabs
may be found via argument-dependent-lookup
(ADL) or by calling one of the std::fabs
overloads. There is a key difference between them however: an overload in
the same namespace as T and found via ADL need not
be defined at the time the function is declared. However,
all the types declared in <boost/cstdfloat.hpp>
are fundamental types, so for these types we are relying on finding an overload
declared in namespace std.
In that case however, all such overloads
must be declared prior to the definition of function unsigned_compare
otherwise they are not considered.
In the event that <boost/cstdfloat.hpp>
has been included after the definition of
the above function, the correct overload of fabs,
while present, is simply not considered as part of the overload set. So the
compiler tries to downcast the float128_t
argument first to long double,
then to double, then to float; the compilation fails because the result
is ambiguous. However the compiler error message will appear cruelly inscrutable,
at an apparently irelevant line number and making no mention of float128: the word ambiguous
is the clue to what is wrong.
Provided you #include <boost/cstdfloat.hpp>
before the inclusion of the any header containing
generic floating point code (such as other Boost.Math headers, then the compiler
will know about and use the std::fabs(std::float128_t)
that we provide in #include <boost/cstdfloat.hpp>.