-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
André,
On 1/16/2011 8:41 AM, André Warnier wrote:
> Ran Berenfeld wrote:
>> well ...no... first evaluate, then assign. and constants are int by
>> default.
>> I think C/C++ would have the same problem...
>>
> Maybe.
FYI they do.
> But then why does the fact of specifying just the first
> right-hand side constant in the calculation as a long, magically change
> the whole result into a long ?
> (1000 * 60 * 60 * 24 * 365) --> int
> (1000L * 60 * 60 * 24 * 365) --> long
Because it promotes the type of the entire expression to "long" and the
laws change for the expression. The assignment works as usual.
There's nothing magical about the first operand: you can cast any of the
operands to trigger this promotion. Here's some C code that demonstrates
it (note that Java's long is 64-bit so we need "long long" which has
spotty ANSI support):
$ cat longtime.c
#include <stdio.h>
int main(int argc, char *argv[]) {
int cacheTime1 = (1000 * 60 * 60 * 24 * 365);
long cacheTime2 = ((long)1000 * 60 * 60 * 24 * 365);
long long cacheTime3 = ((long long)1000 * 60 * 60 * 24 * 365);
long long cacheTime4 = (1000 * 60 * 60 * 24 * (long long)365);
printf("%d\n%ld\n%lld\n%lld\n", cacheTime1, cacheTime2, cacheTime3,
cacheTime4);
return 0;
}
cschultz@dev:~/projects/toys$ cc -ansi -pedantic -Wall -o longtime \
longtime.c && ./longtime
longtime.c: In function `main':
longtime.c:4: warning: integer overflow in expression
longtime.c:5: warning: integer overflow in expression
longtime.c:6: warning: ISO C90 does not support `long long'
longtime.c:6: warning: ISO C90 does not support `long long'
longtime.c:7: warning: ISO C90 does not support `long long'
longtime.c:7: warning: ISO C90 does not support `long long'
longtime.c:9: warning: ISO C90 does not support the `ll' printf length
modifier
longtime.c:9: warning: ISO C90 does not support the `ll' printf length
modifier
1471228928
1471228928
31536000000
31536000000
> But I find this unintuitive.
Most languages' behavior are surprising to Perl programmers :)
Seriously, though, these are the tradeoffs of a strongly-typed language:
you have to be very precise about the way you want calculations to be
performed. The compiler assumes that if you wanted double-precision
integers, you'd ensure that the calculation is done using "long" and not
"int". Presumably, 64-bit operations are (or were) considered slower
than 32-bit operations and so require the coder to specify that 64-bit
operations are desired.
> Specially since it appears that in your first formula, the result is
> overflowing at some point in the calculation, without even a warning (?).
Yes, that's unfortunate: as you can see, the C compiler warns you. But
gcc is quite a bit older and wiser than javac :)
> If someone writes
> Long a = something
> then someone clearly expresses the desire to obtain a Long result.
No, the clarity is in the fact that the target identifier should be able
to store a double-precision value. It says nothing about calculations
that are assigned to it.
If you saw this, would the result (0.0) confuse you?
double d = 1 / 2;
> I suppose that there must be some implacable logic in the way it's done
> now, other than the evil intention to fool the unsuspecting programmer,
> but I honestly fail to see it.
Performance, baby. Java follows C rules, and C was all about performance.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk015g4ACgkQ9CaO5/Lv0PChCwCeMF2Sx0s/Xl6v84FPr96FWwDk
lI0AoImU6lKtFA/D8NUHlzTX8BoblVwM
=A8sz
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
