> On 5 Feb 2023, at 13:54, Werner LEMBERG <w...@gnu.org> wrote:
>
> I see the following error:
>
> rational.cc:68:33: error: call to 'abs' is ambiguous
> num_ = static_cast<uint64_t> (::abs (n));
> ^~~~~
> /usr/include/stdlib.h:129:6: note: candidate function
> int abs(int) __pure2;
> ^
> /Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/cmath:664:1:
> note: candidate function
> abs(float __lcpp_x) _NOEXCEPT {return fabsf(__lcpp_x);}
> ^
> /Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/cmath:668:1:
> note: candidate function
> abs(double __lcpp_x) _NOEXCEPT {return fabs(__lcpp_x);}
> ^
> /Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/cmath:672:1:
> note: candidate function
> abs(long double __lcpp_x) _NOEXCEPT {return fabsl(__lcpp_x);}
> ^
> I'm not a C++ expert, but maybe there is a simple fix
> available?
The ::abs you use, instead of std::abs, is a C compatibility function that the
C++ allows to be defined in the global namespace, and what I can see the effect
depends on the compiler. Older compilers may only have the function int
abs(int) there, and use type conversion before the call, like converting
int64_t to int. When testing the latest GCC and Clang, there seems to be no
difference. Also, include the proper C++ headers, <climits> instead of
<limits.h>, as results also may depend on the compiler.
