Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!gegeweb.org!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: markspace <-@.> Newsgroups: comp.lang.java.programmer Subject: Re: Java puzzler Date: Thu, 12 May 2011 14:32:08 -0700 Organization: A noiseless patient Spider Lines: 39 Message-ID: References: <4db69c13-878f-4806-adb2-a3c5adb1c48c@glegroupsg2000goo.googlegroups.com> <-8mdnSRPEIdA21HQnZ2dnUVZ_j2dnZ2d@earthlink.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Thu, 12 May 2011 21:32:13 +0000 (UTC) Injection-Info: mx03.eternal-september.org; posting-host="IPG0uhtItDWol02AtwWFWQ"; logging-data="7464"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+OjREkxb8oFSOsrwdCCXmm29Wd0WY5jKI=" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 In-Reply-To: Cancel-Lock: sha1:s+5wcIKCe5vWG4Y+THkYur/1CQY= Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:4025 >> On 5/12/2011 1:38 PM, Tom Anderson wrote: >>> Instead, all arithmetic operations, and all casts, should throw >>> an exception if they overflow. Yes! > On 12/05/2011 4:45 PM, Patricia Shanahan wrote: >> >> If we were starting from scratch, that would be an option. As it >> is, it would break far too much code to be possible as a change to >> the existing language. I think, but I'm not sure, arithmetic overflow detection could be made an optional keyword. Thus, new code could have the benefit of overflow detection while existing code would be able to use the current semantics. >> To do that effectively you need a full set of signed and unsigned >> data types, or, better still, arithmetic types with arbitrary value >> ranges. I'm not sure I understand this bit. On 5/12/2011 1:56 PM, Nancy 3 wrote: > There's also the minor little matter of number crunching performance > going straight to hell if every little add or multiply suddenly has > some test-and-branch instructions added near it. I believe arithmetic overflow could be handled efficiently at the machine level, without the need for an explicit test-and-branch. I haven't looked at any datasheets recently, but I recall most CPUs have an option to trap, automatically, on overflow detection.