Re: Hungarian notation - whoops!

[Lawrence Kirby <fred@genesis.demon.co.uk>]

In article <4g9255$74s@goanna.cs.rmit.EDU.AU>
           ok@goanna.cs.rmit.EDU.AU "Richard A. O'Keefe" writes:

>Let me say it again:
>
>        C, like many programming languages, has two mathematically
>        simple functions on ***SIGNED*** integers:
>                -x
>                abs(x)
>        An implementation of C, or any other such language, using
>        ones-complement or sign-and-magnitude arithmetic, easily
>        delivers correct outputs for all legal inputs to these operations.
>
>        An implementation of C, or any other such language, using
>        twos-complement arithmetic, EITHER delivers incorrect outputs
>        for some legal inputs OR requires checking which is in practice
>        seldom offered.

Checking against overflow is required whatever representation is used.
Once this is established using 2's complement is no worse than any other
representation.  Did you see my earlier reply in the thread on this subject?

If nothing else it seems to me that 2's complement is a big win with
regards to implementing multiple-precision arithmetic since lower order
bits of the result of most operations don't depend on the signs of the
operands or the sign of the result.

>The practical consequence of this is that responsibility for ensuring that
>the input to unary minus or absolute value is in range is passed onto the
>programmer.  It is that which I am complaining about.  It doesn't make my
>life as a programmer one teeny tiny bit easier.

It doesn't make it any harder either - see my earlier post.

>>The unsigned type is the ticket for portable integer modulo arithmetic.
>
>Modular arithmetic in Ada 95 *is* the ticket for portable hackery.
>Unsigned arithmetic in C is indeed defined to be modulo 2**n for some
>n, but the bounds on n are very very loose, and the price of portability
>is much programmer-inserted masking.

Well, a small amount of masking.

>More importantly, while overflow in signed arithmetic is a run-time error,
>unsigned arithmetic is very often a design-time error.

True, modulo arithmetic isn't useful in contexts where it simply generates
the wrong result (however it does make it easy to test for overflow after
an unsigned operation).

>For example, suppose I want to count the number of times some event occurs.
>Unless I can *prove* at design time that the event can occur no more than
>65535 times, use of 'unsigned int' in C is a design-time error.

Only if the code doesn't test for wrap to zero. Unsigned types make this
test very easy.

> There is
>at least one "commodity ISA" with a 300Mhz implementation getting close.
>How long is a 32-bit unsigned counter usable with 3e8 events per second?
>
>A little over 14 seconds.

True, it has become important that contemporary languages mandate support
for types longer than 32 bits.

>Overflows aren't the problem.  Restricted machine arithmetic is the problem.

It depends on where you put the limit. Language support for multiple-precision
arithmetic or specified precision beyond 64 bits (or possibly 128 bits)
has some uses but they are rare across the whole spectrum of code.

>>If you
>>don't allow any sort of unaligned access, allowing only contiguous 32-bit
> words
>>to be accessed individually, you force size N arrays of characters to be 4N
>>bytes long. That is seen by some people as a waste of memory. 
>
>You are confusing *unaligned* access with *byte* access.  Like it or not, it
>is a fact that the machines I was talking about DID support byte access,
>DID support packed arrays of character, but did NOT support unaligned
>access.

And there are yet other systems (e.g. Crays) which don't support byte access
but compilers can still support characters arrays where the character unit
is smaller than the machine word unit by bit twiddling tricks.

-- 
-----------------------------------------
Lawrence Kirby | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------