Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: "MikeP" Newsgroups: comp.lang.java.programmer Subject: Re: Arithmetic overflow checking Date: Fri, 15 Jul 2011 00:28:15 -0500 Organization: A noiseless patient Spider Lines: 85 Message-ID: References: <015aeb15-57db-48ab-9cd4-77f8448b632f@w24g2000yqw.googlegroups.com> <2rydnez7l-H5BYnTnZ2dnUVZ_vGdnZ2d@earthlink.com> <9LWdnZH2hdfmyYvTnZ2dnUVZ_vidnZ2d@posted.palinacquisition> Injection-Date: Fri, 15 Jul 2011 05:50:24 +0000 (UTC) Injection-Info: mx04.eternal-september.org; posting-host="JFpB2gvi06BqMH/s1e1Gsw"; logging-data="25876"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX198UfGZYN6EVfF1zbYjCoeC" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-RFC2646: Format=Flowed; Response X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 Cancel-Lock: sha1:+ECdUuAe+377QHm7zfLcFVgsAbA= X-Priority: 3 X-MSMail-Priority: Normal Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:6202 Peter Duniho wrote: > On 7/7/11 10:02 AM, Patricia Shanahan wrote: >> On 7/7/2011 7:11 AM, Peter Duniho wrote: >>> On 7/6/11 10:16 AM, Patricia Shanahan wrote: >>>> On 7/6/2011 8:35 AM, rop rop wrote: >>>>> Hi, >>>>> >>>>> If I want to have arithmetic-overflow checking in all parts of an >>>>> application, >>>>> what is the most practical, simple, efficient way to achieve this? >>>> >>>> Write the application in Ada. >>> >>> Or use C#, which has the same feature, but is a lot more like Java >>> otherwise. >>> >>> That said, I suspect Tom's guess is correct and a language-change >>> just to achieve this goal isn't going to be the practical choice. >> >> Like most design decisions, it is a trade-off. If Tom *needs* >> overflow checking, the most practical, simple, efficient way to >> achieve it is to use a language that is designed to support overflow >> checking. > > To be clear, I don't think _Tom_ needs or doesn't need this. He was > simply replying to the OP. > >> If he merely *wants* overflow checking, the best choice may be to >> stick to Java and drop general overflow checking. That does not >> prevent having e.g. a BigInteger subclass that takes a range as a >> constructor parameter and does overflow checking against that range. > > I don't disagree with that. In fact, I'm skeptical that in any > program it really makes sense to apply overflow checking to _every_ > computation, even not counting the issues that have already been > pointed out wrt the JDK itself and other libraries which rely on the > lack of it. For example, does every integral "for" loop _really_ > need the index increment operation to be checked for overflow? Seems > unlikely to me. It's Java. Why worry about performance?! And how expensive really is it? Instead of just increment, increment and check the hardware overflow flag. (Oops, did I say "hardware" in a Java NG? My bad). > > While the discussion has been interesting, I can't help but feel that > the original question is fundamentally flawed. The answers are mostly > academic, as it's unlikely anyone really ought to be trying to > approach the problem in this way in the first place. It's as easy as setting a compiler switch in some languages (not in C or C++ though, but C#, e.g.), so the approach seems sound and desireable for a language to implement. The programmer shouldn't be overly burdened with the task of overflow checking. > >> I have not yet seen an option for getting general overflow checking >> in Java, without getting false hits on code that depends on the JLS >> specified arithmetic behavior, that is at all practical, simple, or >> efficient. > > Well, I think Tom's suggestion of some sort of automatic code-rewriter > _could_ be the best solution in _certain_ scenarios. Such an > implementation could be applied selectively to specific code. > > I would not worry about the "simple" or "efficient" criteria. IMHO, > if one is deciding to apply overflow checking to every computation, > one has already abandoned the hope of efficiency. I don't think that is true. It depends on the application of course, but for most programs, wouldn't a single-digit performance hit be acceptable? (OK, maybe not on already slow Java ;) ). > Frankly, as long as the discussion is purely hypothetical (as it is > now), I don't see how anyone can claim with 100% certainty the broad > superiority or inferiority of any given solution. It's too dependent > on the specifics of whatever real-world scenario is at hand. > I think the issue has achieved critical mass (programmers, not just comp scientists) now and every language needs to "keep up with the Joneses" (C#) to stay relevant.