I can't reproduce it on any of the systems I have available
here. (Solaris on Sparc, with g++ 4.1.0 or Sun CC 5.8; Linux
2.6.9 on Intel, with g++ 4.1.0, and Windows XP with VC++ 14).
Of course, for all but Linux, I had to modify the code to get it
to compile.
This header is not standard C++, and is only available if you
have C99 as well. (Which means that I would normally expect it
pretty much everywhere---but my expectations are disappointed;
it's present neither under Solaris nor Windows.)
Never compare 2 floats for equality.
Which is very poor advice. In this particular case, comparison
for equality is exactly what he wants.
Apart from the fact that its an intensive operation for a cpu,
Since when? It's as fast as any other comparison, integral or
floating point, on the machines available to me.
the following is expected...
int main()
{
float fa(0.0f);
float fb(0.0f);
if( fa == fb)
std::cout << "not equal\n";
else
std::cout << "equal\n";
std::cout << "Press ENTER to EXIT.\n";
std::cin.get();
}
Are you kidding? Any compiler which outputs "not equal" with
that program is seriously broken.
And z might be -0.000000001f. Or 1e30. Or anything else. The
whole point is that he doesn't know, and that he doesn't want to
divide by zero. The only correct test is thus:
if ( z != 0.0F )
Anything else is a programming error, and shows a complete lack
of understanding of how machine floating point works.
Note that in his actual code, the function is only called with z
equal 130.0. Which can't be 0.0, anyway you cut it, and will
always be greater than 0.0. (For that matter, I don't know of a
machine where it won't be represented exactly.)
For the original poster: does adding the option -ffloat-store
have any effect? G++ isn't fully standards compliant without
it. Not that I think that it could affect your program; all of
the values you use are exactly representable. (It could affect
the program if the value you are comparing with 0.0 is the
result of an expression, and in some strange way, the compiler
picks it up from a register in the comparison, but reloads it
from memory for the division. And the actual real intermediate
results were smaller than 1E-38.) For Intel processors, g++
also accepts -mpc64 and -mpc32, which cause all intermediate
values to be rounded to 64 or 32 bits---this will not only
eliminate excess precision in the intermediate values, but may
also run a little bit faster (particularly on older hardware.
