On Sun, Jan 16, 2011 at 08:41, André Warnier <a...@ice-sa.com> 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. 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 ?
It's not magic. For each * operation, if one operand is int and one is long, the compiler does a 64-bit multiply and produces a long result. Now, consider each "*" in that expression (in order of evaluation) and ask, What type is each operand? Some people would explicitly write "(1000L * 60L * 60L * 24L * 365L)" to avoid this sort of head-scratching. > (1000 * 60 * 60 * 24 * 365) --> int > (1000L * 60 * 60 * 24 * 365) --> long > > Note: my intention is not to start a rant or a flame on the way Java does > things. > I suppose that the Java syntax rules describe this accurately. > But I find this unintuitive. > Specially since it appears that in your first formula, the result is > overflowing at some point in the calculation, without even a warning (?). Yep, there's no overflow checking for arithmetic on primitive types. For the sake of efficiency, I presume. > > If someone writes > Long a = something > then someone clearly expresses the desire to obtain a Long result. > And if for some obscure reason that was really not the case, one could > always write > Long a = (int) something > > 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. There certainly are logical rules behind it. If you want the "why", I guess you'd have to ask Jim Gosling. -- Len --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
