I checked the difference between abs
and fabs
on python here
As I understand there are some difference regarding the speed and the passed t
With C++ 11, using abs()
alone is very dangerous:
#include <iostream>
#include <cmath>
int main() {
std::cout << abs(-2.5) << std::endl;
return 0;
}
This program outputs 2
as a result. (See it live)
Always use std::abs()
:
#include <iostream>
#include <cmath>
int main() {
std::cout << std::abs(-2.5) << std::endl;
return 0;
}
This program outputs 2.5
.
You can avoid the unexpected result with using namespace std;
but I would adwise against it, because it is considered bad practice in general, and because you have to search for the using
directive to know if abs()
means the int
overload or the double
overload.
My Visual C++ 2008 didn't know which to choice from long double fabs(long double)
, float fabs(float)
, or double fabs(double)
.
In the statement double i = -9;
, the compiler will know that -9
should be converted to double
because the type of i
is double
.
abs()
is declared in stdlib.h
and it will deal with int
value.
fabs()
is declared in math.h
and it will deal with double
value.
In C++, std::abs
is overloaded for both signed integer and floating point types. std::fabs
only deals with floating point types (pre C++11). Note that the std::
is important, the C function ::abs
that is commonly available for legacy reasons will only handle int
!
The problem with
float f2= fabs(-9);
is not that there is no conversion from int
(the type of -9
) to double
, but that the compiler does not know which conversion to pick (int
-> float
, double
, long double
) since there is a std::fabs
for each of those three. Your workaround explicitly tells the compiler to use the int
-> double
conversion, so the ambiguity goes away.
C++11 solves this by adding double fabs( Integral arg );
which will return the abs
of any integer type converted to double
. Apparently, this overload is also available in C++98 mode with libstdc++ and libc++.
In general, just use std::abs
, it will do the right thing. (Interesting pitfall pointed out by @Shafik Yaghmour. Unsigned integer types do funny things in C++.)