Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Eric Sosman Newsgroups: comp.lang.java.programmer Subject: Re: Java puzzler Date: Thu, 12 May 2011 22:27:50 -0400 Organization: A noiseless patient Spider Lines: 30 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: Fri, 13 May 2011 02:27:53 +0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="BrOwaJANne849xlH+KPYjQ"; logging-data="18822"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+Ze7RrKCipLIifl4qiB6fC" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 In-Reply-To: Cancel-Lock: sha1:NLTPXcXCw6I3EDfc6tt80Ir7eUU= Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:4037 On 5/12/2011 4:56 PM, Nancy 3 wrote: > On 12/05/2011 4:45 PM, Patricia Shanahan wrote: >> On 5/12/2011 1:38 PM, Tom Anderson wrote: >>> Instead, all arithmetic operations, and all casts, should throw an >>> exception if they overflow. Then, if a string of operations does not do >>> anything surprising, the matter of casting is moot, and if they do, they >>> blow up, so it is also moot. >> >> If we were starting from scratch, that would be an option. To do that >> effectively you need a full set of signed and unsigned data types, or, >> better still, arithmetic types with arbitrary value ranges. It would be >> a step towards Ada, rather than Java's predominantly C and C++ heritage. >> >> As it is, it would break far too much code to be possible as a change to >> the existing language. > > 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. Double the instructions > along the main code path, halve the speed, in all likelihood. Maybe CPU > based branch prediction would help somewhat. You'd also hit the limits > on the code cache that much sooner. Not so bad as you think, if you run the program on a proper machine with hardware overflow traps. Oh, those have gone out of fashion? No wonder software is so solidly reliable nowadays ... -- Eric Sosman esosman@ieee-dot-org.invalid