or give you the "default" precision. And note that this problem is not
what you pointed out initially, but something I gave.
That is it, whole point, what the heck is a default literal or precision
in a generic code?
double occupies less space and can use SSE instructions.
float faster and use half of double, that is not a valid argument, and it
is not a valid answer to the problem at hand.
If i want double i must state it "0.5d", float "0.5f" real "0.5L", we are
talking about again "generic" code.
There are too many implicit casts, main reason is because there are
default literals, am i wrong?
invalid code?
probably
T inv(T)(T m) {
return 1 / m;
}
Now you are just doing it for the sake of argument. :P
This is another function, for another purpose.
Integers are the only values that can be represented without any
approximation (unless you resort to rationals, or inefficient
representations that are probably ok only at compile time or in very
specific applications).
So generic code should use integers, not floating points.
You might argue that the way to get a floating point literal of type T
is ugly:
cast(T)1.0
for example fortran uses 1.0_T, but one can definitely live with it,
anyway normally you should use integers, generic floating point literals
is not really something that is so well defined...
This is not only about floating point types, same applies to integers.
3 is default "int" right?
Imagine what happens if it wasn't.
ushort m0 = 30000000000000000000000000000000000; // error
ubyte m1 = 3; // no implicit cast, fine
byte m2 = 3; // same
short m3 = 3; // same
ubyte m5 = -3; // error
ushort m6 = -3; // error
And for the floating point case :
float m = 0.5;
double n = 0.5;
real r = 0.5;
What is wrong with this?
Thanks.
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/