In standard-conforming code that has included cmath and only calls std::abs on floats, doubles, and long doubles, there is no difference. However, it is instructive to look at the types returned by std::abs on various types when you call it with various sets of header files included.
On my system, std::abs(-42) is a double if I've included cmath but not cstdlib, an int if I've included cstdlib, and it produces a compilation error if I've included neither. Conversely, std::abs(-42.0) produces a compilation error (ambiguous overload) if I've included cstdlib but I haven't included cmath or a different compilation error (never heard of std::abs) if I've included neither.
On my platform, std::abs('x') gives me a double if I've included cmath or an int if I've included cstdlib but not cmath. Similar for a short int. Signedness does not appear to matter.
On my platform, the complex header apparently causes both the integral and the floating-point overloads of std::abs to be declared. I'm not certain this is mandated; perhaps you can find an otherwise reasonable platform on which std::abs(1e222) returns infinity with the wrong set of standard headers included.
The usual consequence of "you forgot a header in your program" is a compilation failure complaining of an undefined symbol, not a silent change in behaviour. With std::abs, however, the result can be std::abs(42) returning a double if you forgot cstdlib or std::abs('x') returning an int if you didn't. (Or perhaps you expected std::abs to give you an integral type when you pass it a short? Then, assuming my compiler got its promotion and overload resolution right, you had better make sure you don't include cmath.)
I have also spent too much time in the past trying to work out why code like double precise_sine = std::sin(myfloat) gives imprecise results. Because I don't like wasting my time on these sorts of surprises, I tend to avoid the overloaded variants of standard C functions in namespace std. That is, I use ::fabs when I want a double to be returned, ::fabsf when I want a float out, and ::fabsl when I want a long double out. Similarly for ::abs when I want an int, ::absl when I want a long, and ::absll when I want a long long.
In standard-conforming code that has included cmath and only calls std::abs on floats, doubles, and long doubles, there is no difference. However, it is instructive to look at the types returned by std::abs on various types when you call it with various sets of header files included.
On my system, std::abs(-42) is a double if I've included cmath but not cstdlib, an int if I've included cstdlib, and it produces a compilation error if I've included neither. Conversely, std::abs(-42.0) produces a compilation error (ambiguous overload) if I've included cstdlib but I haven't included cmath or a different compilation error (never heard of std::abs) if I've included neither.
On my platform, std::abs('x') gives me a double if I've included cmath or an int if I've included cstdlib but not cmath. Similar for a short int. Signedness does not appear to matter.
On my platform, the complex header apparently causes both the integral and the floating-point overloads of std::abs to be declared. I'm not certain this is mandated; perhaps you can find an otherwise reasonable platform on which std::abs(1e222) returns infinity with the wrong set of standard headers included.
The usual consequence of "you forgot a header in your program" is a compilation failure complaining of an undefined symbol, not a silent change in behaviour. With std::abs, however, the result can be std::abs(42) returning a double if you forgot cstdlib or std::abs('x') returning an int if you didn't. (Or perhaps you expected std::abs to give you an integral type when you pass it a short? Then, assuming my compiler got its promotion and overload resolution right, you had better make sure you don't include cmath.)
I have also spent too much time in the past trying to work out why code like double precise_sine = std::sin(myfloat) gives imprecise results. Because I don't like wasting my time on these sorts of surprises, I tend to avoid the overloaded variants of standard C functions in namespace std. That is, I use ::fabs when I want a double to be returned, ::fabsf when I want a float out, and ::fabsl when I want a long double out. Similarly for ::abs when I want an int, ::absl when I want a long, and ::absll when I want a long long.
Is there any difference at all between std::abs and std::fabs when applied to floating point values?
No there is not. Nor is there a difference for integral types.
It is idiomatic to use std::abs() because it is closest to the commonly used mathematical nomenclature.
Hey guys, I have a very simple code, which is the following:
#include <iostream>
#include <cmath>
int main()
{
double a = 2.1;
double b = abs(a);
std::cout << b;
}The output I get is b=2. Which doesn't really make sense to me. The output should just be 2.1, no?
Thanks in advance!
The correct overloads are guaranteed to be present in <cmath>/<cstdlib>:
C++11, [c.math]:
In addition to the
intversions of certain math functions in<cstdlib>, C++ addslongandlong longoverloaded versions of these functions, with the same semantics.The added signatures are:
long abs(long); // labs() long long abs(long long); // llabs()[...]
In addition to the
doubleversions of the math functions in<cmath>, overloaded versions of these functions, with the same semantics. C++ addsfloatandlong doubleoverloaded versions of these functions, with the same semantics.float abs(float); long double abs(long double);
So you should just make sure to include correctly <cstdlib> (int, long, long long overloads)/<cmath> (double, float, long double overloads).
You cannot guarantee that std::abs(x) will always return |x| for all arithmetic types. For example, most signed integer implementations have room for one more negative number than positive number, so the results of abs(numeric_limits<int>::min()) will not equal |x|.