On Tue, 19 Apr 2011 20:37:47 -0400, bearophile <[email protected]>
wrote:
dsimcha:
I know what you suggest could prevent bugs in a lot of
cases, but it also has the potential to get in the way in a lot of
cases.
You are right, and I am ready to close that enhancement request at once
if the consensus is against it.
double->float and real->float cases are not so common. How often do you
use floats in your code? In my code it's uncommon to use floats,
generally I use doubles.
I do GP GPU work, so I use floats all the time. They're also useful for
data storage purposes.
A problem may be in real->double conversions, because I think D feels
free to use intermediate real values in some FP computations.
For your information, the x87 can only perform computations at 80-bits. So
all intermediate values are performed using reals. It's just how the
hardware works. Now I now some compilers (i.e. VS) allow you to set a
flag, which basically causes the system to avoid intermediate values
altogether or to use SIMD instructions instead in order to be properly
compliant.
Another possible problem: generic code like this is going to produce an
error because 2.0 literal is double, so x*2.0 is a double even if x is
float:
T foo(T)(T x) {
return x * 2.0;
}
But when I use floats, I have found it good a C lint that spots
double->float conversions, because it has actually allowed me to speed
up some code that was doing float->double->float conversions without me
being aware of it.
Yes, this auto-promotion of literals is very annoying, and it would be
nice if constants could smartly match the expression type. By the way,
C/C++ also behave this way, which has gotten me into the habit of adding f
after all my floating point constants.
