From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 10a146,a03ae7f4e53958e1 X-Google-Attributes: gid10a146,public X-Google-Thread: fac41,a03ae7f4e53958e1 X-Google-Attributes: gidfac41,public X-Google-Thread: 1094ba,a03ae7f4e53958e1 X-Google-Attributes: gid1094ba,public X-Google-Thread: fa0ae,a03ae7f4e53958e1 X-Google-Attributes: gidfa0ae,public X-Google-Thread: 114809,a03ae7f4e53958e1 X-Google-Attributes: gid114809,public X-Google-Thread: 1014db,a03ae7f4e53958e1 X-Google-Attributes: gid1014db,public X-Google-Thread: 109fba,a03ae7f4e53958e1 X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,8775b19e3c68a5dc X-Google-Attributes: gid103376,public From: "Dann Corbit" Subject: Re: Which language pays most? Smalltalk, not C++ nor Java. Date: 1997/12/30 Message-ID: <68c66j$ei3$1@client3.news.psi.net>#1/1 X-Deja-AN: 311486576 Content-Transfer-Encoding: 7bit References: <199712121931.LAA25389@sirius.infonex.com> <685mee$5d4$1@sparcserver.lrz-muenchen.de> <34A812F9.C169A703@its.cl> <68bu22$geg$1@brie.direct.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Organization: PSINet Newsgroups: comp.lang.fortran,comp.lang.c,comp.lang.c++,comp.lang.eiffel,comp.lang.java.programmer,comp.lang.smalltalk,comp.lang.perl.misc,comp.lang.ada,comp.edu Date: 1997-12-30T00:00:00+00:00 List-Id: Robert Dewar wrote in message ... >Kaz says > ><for sign reversal, you would have to depend on a particular platform's >handling of overflow. On two's complement systems, overflow on addition or >subtraction can be detected by examining the most significant bit of the >result and those of the operands. This isn't true in general, however. > >It's possible to determine whether a given operation will occur by >writing a test expression (or assertion) which itself does not invoke >overflow. >>> > > >Yes, it is possible, but gruesome, especially for multiplication. And rather >silly, since at the hardware level it is typically easy to detect overflow. >The lack of overflow detection in a language like C++ seems a clear and >annoying ommission (actually I had been told this was fixed in the latest >standard, but I guess that was false information). Anyway, the Ada approach >makes far more sense than appealing to highly dubious assertions! Now, with Ada we can simply declare precision, and I will agree this is very nice. But we can make the same sort of decisions for other languages and use efficient fixed sizes or new types of our own design. Instead of growing a bit at a time, we grow in jumps. Now, if I declare a type of 60 bits of precision, am I guaranteed that it will never overflow? Obviously, I still have to perform the same analysis that I would need for any other software system. Getting exactly what you want is much easier, though. Exception handling is not perfect a solution either. It is even better to engineer a solution where the types used never extend beyond the design range. If there is any possibility that a counter of type short is not large enough, use long. And if there is any chance that long is too small, use a larger type or invent one. Same for float, double, long double. Exception handling for memory or disk problems makes excellent sense, since those are often limited resources of unknown quantity. But integer overflow and the like is an indication of a serious flaw in the original physical design. If an exhaustive test of the domain is applied, using assert() is as good as any other method, and it has the added benefit of documenting the thinking of the software analyst very concisely. However, with more than 5 bytes of data length in the domain, exhaustive testing is prohibitive. -- C-FAQ ftp sites: ftp://ftp.eskimo.com ftp://rtfm.mit.edu Hypertext C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html C-FAQ Book: ISBN 0-201-84519-9. Want Software? Algorithms? Pubs? http://www.infoseek.com