Re: Which language pays most? Smalltalk, not C++ nor Java.

["Dann Corbit" <dcorbit@solutionsiq.com>]

Robert Dewar wrote in message ...
>Kaz says
>
><<That is absurd. Overflow invokes undefined behavior in C++. To check
>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