Re: Hungarian notation

Re: Hungarian notation

[Bob Kitzberger]

Michael Feathers (feathers@gate.net) wrote:
:
: If anyone does not think that type is important information that ought
: to kept in mind for semantic purposes, just consider this: someone
: anonymously offers you sex.  The type of person offering it should
: be important to you, unless you are bisexual, and even then you
: might like to know as some casting may be required.  :-)

C, no HN:   you directly attempt to mate regardless of target sex

C, HN:      you rely on the name of the person to determine their sex, and
	    then attempt to mate if the name matches.  Roberta and Robert
	    live interesting lives.

Ada,C++ w tools: you ask your tricorder about the sex of the person before 
		 attempting to mate.

	    


: -Mike (master of silly analogies)

Re: Hungarian notation

[Joachim Durchholz]

Mike.Palmer@tus.ssi1.com wrote 06.01.96 on Re: Hungarian notation:

> Joachim Durchholz wrote:
> >
> > > Consider also that variable names may be misleading anyway. In that
> > > sense there's no great difference between
> > >
> > >         someProc(MyString)
> > >
> > > and
> > >
> > >         someProc(pszMyString)
> > >
> > > either could quite happily refer to any other data type.
> > >
> >
> > This example does not occur in real life. Or rather, it better should not!
> > Anybody using meaningless names like "MyString" should be thrown out of
> > the programming business. Depending on the actual semantics of "someProc",
> > the parameter should be called "Message" or "Options" or "ParserInput" or
> > whatever.
> >
> > -Joachim
>
> One hopes you just missed the point here. Hungarian notation does not
> attempt to help you keep track of _what_ your variable is, it gives you a
> framework to keep track of what _kind_ of variable it is. One would also
> note that someProc is not a very descriptive name, but so what? In the first
> example, I have _no_ clue what type of variable MyString is, although I
> could probably deduce that it is a string. In the second example, the  
prefix
That's exactly what I meant. Sorry that I didn't make my point clear.
> tells me that it is a Pointer to a Zero terminated String.


-Joachim

--
Im speaking for myself here.
## CrossPoint v3.02 ##

Re: Hungarian notation

[vancleef]

In article <4crm6i$24mi@navajo.gate.net>, feathers@gate.net (Michael Feathers) writes:
> Todd Knarr (tknarr@xmission.com) wrote:
> : In <1996Jan7.045815.8676@ohstpy>, vancleef@ohstpy.mps.ohio-state.edu writes:
> : 
> : >How often do you use NON-ZERO terminated strings??? HN is
> : >useless garbage in C++, or for ANSI C compilers.
> 
> Not so.  I use HN in C++ all the time.  It is excellent in the presence 
> of polymorphism.



Huh? How?

> 
> : That's the big downside to HN: it simply cannot be sensibly extended to
> : deal with an arbitrarily large number of types, and it goes completely
> : insane dealing with polymorphism. I doubt anyone could come up with a
> : reasonable HN prefix to accomodate a variable that can be one of 9
> : different types at any given time.
> 
> I've never seen a variable that can be any of 9 different types in C++.
> All variables have a type.  Period.  A type can be a union or a base 
> class, but all variables have one and only one type in C++.  If you don't
> believe me, check the ARM.
> 

Re: Hungarian notation

[Michael Feathers]

Todd Knarr (tknarr@xmission.com) wrote:
: In <1996Jan7.045815.8676@ohstpy>, vancleef@ohstpy.mps.ohio-state.edu writes:
: 
: >How often do you use NON-ZERO terminated strings??? HN is
: >useless garbage in C++, or for ANSI C compilers.

Not so.  I use HN in C++ all the time.  It is excellent in the presence 
of polymorphism.

: That's the big downside to HN: it simply cannot be sensibly extended to
: deal with an arbitrarily large number of types, and it goes completely
: insane dealing with polymorphism. I doubt anyone could come up with a
: reasonable HN prefix to accomodate a variable that can be one of 9
: different types at any given time.

I've never seen a variable that can be any of 9 different types in C++.
All variables have a type.  Period.  A type can be a union or a base 
class, but all variables have one and only one type in C++.  If you don't
believe me, check the ARM.

Re: Hungarian notation

[Adam Beneschan]

feathers@gate.net (Michael Feathers) writes:
>
>   If anyone does not think that type is important information that ought
>   to kept in mind for semantic purposes, just consider this: someone
>   anonymously offers you sex.  The type of person offering it should
>   be important to you, unless you are bisexual, and even then you
>   might like to know as some casting may be required.  :-)
>
>
>   -Mike (master of silly analogies)

I agree with your last point--i.e. that this is a silly analogy.  To
carry the silliness even further: you probably care what gender a
person is before you have sex with them, but if you're an employer
looking for someone to fill a position, you probably don't, or
shouldn't, care; all you're concerned with is what purpose you're
going to be using the person for.

Now, which of these analogies corresponds more closely to how
variables in a program are used?

(1) Using the variables for a purpose
(2) Having sex with the variables

:-)
                                -- Adam

Re: Hungarian notation

[Michael Feathers]

Bob Kitzberger (rlk@rational.com) wrote:
: Michael Feathers (feathers@gate.net) wrote:
: :
: : If anyone does not think that type is important information that ought
: : to kept in mind for semantic purposes, just consider this: someone
: : anonymously offers you sex.  The type of person offering it should
: : be important to you, unless you are bisexual, and even then you
: : might like to know as some casting may be required.  :-)
: 
: C, no HN:   you directly attempt to mate regardless of target sex
: 
: C, HN:      you rely on the name of the person to determine their sex, and
: 	    then attempt to mate if the name matches.  Roberta and Robert
: 	    live interesting lives.

Naa...  mlRobert is male and flRobert is female  :)

Re: Hungarian notation

[Todd Knarr]

In <hawkfish-0801960904580001@blv-pm3-ip24.halcyon.com>, hawkfish@punchdeck.com (Richard Wesley) writes:

>I've found it useful to use typedefs for all sorts of things like this. 
>Looping through a FooArray with a FooIndex is much more robust than using
>a long or something.

I try to avoid syntactic-saccharine typedefs when possible. There's no
language-level gain from typedef'ing an int or long to something else
just for that, and it virtually requires an explosion of variables to
deal with multiple arrays of different types. The result of using several
different variables to step through several different arrays at different
times, just because those arrays have elements of different types, tends
to be confusion. When the index is really significant then it makes sense
to use seperate variables ( eg. when nCurrentMerchItem holds the index of
the current item as other processing is done ), but as was pointed out
there are a lot of constructions where the index is only significant for
a line or two of code ( where your code is saying, basically, "Do >this<
to every item in the array." ).

One of my rules is that, when I do something like that, I use integer
variables like i and j. That maps nicely to the uses of such letters in
math classes and the like. I can then tell instantly whether the indexes
are significant or just grind work.

>This is reasonable for C, but these days I find myself using auto_ptr and
>my own auto_array templates to deal with this problem.  On the other hand,
>it could still be useful inside a class that used an array to represent
>something (e.g. a string).

Even in a lot of higher-level things like your auto_array it makes sense
to index things by an integral value. There's a significant gain in safety
at times, but at others you simply introduce redundant checks. If, for
instance, an index is validated once and never altered after that, there
is no need to revalidate it on every access. ( NB: being certain the index
will never become invalid is, of course, the trick. )

--
Todd Knarr : tknarr@xmission.com      |  finger for PGP public key
                                      |  Member, USENET Cabal

Seriously, I don't want to die just yet.  I don't care how
good-looking they are, I! don't! want! to! die!"
                                        -- Megazone ( UF1 )

Re: Hungarian notation

[Michael Feathers]

Todd Knarr (tknarr@xmission.com) wrote:
: In <4crm6i$24mi@navajo.gate.net>, feathers@gate.net (Michael Feathers) writes:
: >I've never seen a variable that can be any of 9 different types in C++.
: >All variables have a type.  Period.  A type can be a union or a base 
: >class, but all variables have one and only one type in C++.  If you don't
: >believe me, check the ARM.
: 
: You haven't worked with polymorphic classes as reference arguments or
: pointers much, then. I have the following class heirarchy:

Yeah, I have.

In your example (deleted for space) you mention that a
reference can stand in place for objects of any of its derived types.

I said that all variables have one-and-only-one-type.  The reference
itself is a variable (as pointers are) and it has a type.

This may seem like a quibbling point, but in OOP it should be a natural
assumption (because of polymorphism) that all objects of derived
classes should perform in a manner appropriate to their class in
the context of their base classes interfaces.  This is information
hiding, in much the same way as function names hide implementation 
yet provide semantic information.  If this is not the case, then the 
inheritance should be suspect.

: Give me an HN prefix that tells me that, in the following prototype
: 
: Stall *HardwareChangeSignalled( Stall& ExistingStall, int ByteCount,
:                                 unsigned char *aHardwareData );
: 
: the ExistingStall argument is one of the 9 subclasses and never a Stall,
: and the returned pointer is one of the 9 subclasses and never a pointer to
: Stall.

Why never a Stall?  If Stall's interface is present in any of its derived
classes, Stall calls should be resolved.

: Without such a prefix, you can readily get the obnoxious situation of a new
: programmer depending on the prefix and not realizing that he is dealing with
: a polymorphic type. This can cause him problems if he refers to the source
: code for Stall, depending on the HN prefix to be the actual type.

True enough, but I think that new OOP programmers should drill it into
their heads that references==pointers as far as polymorphism goes (and
in other ways too).  Polymorphism has to change the way that you understand
code.  We are not in Kansas any more. 

Re: Hungarian notation

[Todd Knarr]

In <4crm6i$24mi@navajo.gate.net>, feathers@gate.net (Michael Feathers) writes:
>I've never seen a variable that can be any of 9 different types in C++.
>All variables have a type.  Period.  A type can be a union or a base 
>class, but all variables have one and only one type in C++.  If you don't
>believe me, check the ARM.

You haven't worked with polymorphic classes as reference arguments or
pointers much, then. I have the following class heirarchy:

Stall
        AvailableStall
        AssignedStall
        OccupiedStall
        DirtyStall
        BeingCleanedStall
        BrokenStall
        OutOfServiceStall
        AlarmStall
        OfflineStall

That's 9 subclasses of Stall. I do, though, routinely have arguments that
are pointers or references to Stall. The actual object may be any one of
those 9 subclasses.

Give me an HN prefix that tells me that, in the following prototype

Stall *HardwareChangeSignalled( Stall& ExistingStall, int ByteCount,
                                unsigned char *aHardwareData );

the ExistingStall argument is one of the 9 subclasses and never a Stall,
and the returned pointer is one of the 9 subclasses and never a pointer to
Stall.

Without such a prefix, you can readily get the obnoxious situation of a new
programmer depending on the prefix and not realizing that he is dealing with
a polymorphic type. This can cause him problems if he refers to the source
code for Stall, depending on the HN prefix to be the actual type.

--
Todd Knarr : tknarr@xmission.com      |  finger for PGP public key
                                      |  Member, USENET Cabal

Seriously, I don't want to die just yet.  I don't care how
good-looking they are, I! don't! want! to! die!"
                                        -- Megazone ( UF1 )

Re: Hungarian notation - whoops!

[Richard A. O'Keefe]

I wrote:
    The underlying base is not something I usually have to think about.
    Most of my C code would work just as well in base 2, 3, 10, or even
    balanced ternary.

c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku) writes:

>But that is irrelevant since the standard restricts C to binary architectures.

Irrelevant to what?  I *know* what the C standard requires.  I keep a copy
of the C standard (and the draft C++ standard, and Pascal, and Pascal
Extended, and Ada 83, and Ada 95) close by my desk for handy reference.
(The Fortran standards I have read on microfiche in the library.)

Of necessity, my Fortran and Pascal code cannot depend on the machine base.
The fact that most of my C code turns out not to depend on the machine
base even though it _could_ is most certainly relevant to a discussion of
arithmetic in programming languages.  The form of my argument was "how
much more".

It so happens that the C standard was carefully crafted to allow
2s complement, 1s complement, AND sign-and-magnitude.

I wrote:
    But the fact that abs(x) may deliver a negative
    number is something I have to live with the whole time.

Kazimir Kyheku again completely misses the point by a country mile.

>Not true. If you use the unsigned type, there is no such thing as overflow.
>It's called residue math. No operation between two unsigned numbers yields
>undefined results. The "X % Y" operation between unsigned numbers gives you the
>smallest positive residue of X with respect to Y. Nothing undefined or
>overflown about that. 

Kazimir, you will get a LOT further in life if you realise that people who
disagree with you sometimes know what they are talking about.

The abs function in C is defined by the standard to take SIGNED int as
parameter and deliver SIGNED int as result.  I am not claiming now, did
not claim in the quoted message, and have never claimed in the past that
C has no arithmetic types which cannot overflow.  (Actually, in UNIX
Version 6, C _didn't_ have unsigned arithmetic; one did arithmetic on
pointers to get unsigned.  I kid you not.)  By the way, "X % 0" is still
undefined in unsigned arithmetic, so the claim that there is "nothing
undefined" about it is not true.

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.

Now, it so happens that a C compiler _is_ free to generate overflow checks
for signed integer arithmetic, so a twos-complement implementation COULD
guarantee "correct result or exception in all cases".  This is occasionally
done for Pascal compilers.  I have access to three C compilers (lcc, gcc,
and SPARCompiler cc) and if any of them has an option to check that signed
arithmetic is done correctly I would be most grateful to be told what it is.

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.

>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.

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

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.  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.

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

>You need unaligned access if you want to have packed character arrays.

Sorry, but this simply isn't true.  It may surprise you to know that Pascal
(the programming language which introduced the term 'packed') was first
implemented on a machine which did not have unaligned access.  The
machine in question had 60-bit words, 6 bit characters, and no character
addressing, only word addressing (which made unaligned access impossible
to express).

>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.

(Kazimir Kylheku) then contradicts himself and writes

>Just because a machine does enforce alignment doesn't mean that C cannot
>operate on packed byte arrays.

>Chances are that you may even be working on an architecture whose compiler does
>this, and not even know it! :)

I am working on a SPARC.  I also keep the SPARC V8 ABI manual close to my
desk, and know it pretty well.  Architectures don't have unique compilers.
I use three compilers.  I've only read one of them (lcc), but I occasionally
check the output of the others (gcc, cc).  There are several other compilers
for this architecture, including one which doesn't use register windows.

-- 
Election time; but how to get Labour _out_ without letting Liberal _in_?
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.

Re: Number representation (was: Hungarian notation - whoops!)

[Richard A. O'Keefe]

tsw@3do.com (Tom Watson) writes:

>In article <4fms62$c0p@goanna.cs.rmit.EDU.AU>, ok@goanna.cs.rmit.EDU.AU
>(Richard A. O'Keefe) wrote:

>> 
>> >By the way, S&M is of course the right representation of floating-point,
>> >using 2's complement for floating-point is a goof that only a designer
>> >not understanding fpt would make!
>> 

I did _not_ write that, I _quoted_ it.

>I'm not so sure.  With sign & magnitude you get TWO representations of the
>same number (zero).

In the B6700, you did indeed get two representations of 0, but unless you
used some non-standard extensions
	(-0 .EQ. 0) but (.NOT.(-0 .IS. 0))
nothing in your program could depend on this fact.  The presence of two
signed integer zeros (which were the same as the two signed floating point
zeros) was something that a programmer could and did completely ignore.
All the hardware had to do was to make sure that -0 and +0 acted the same
in ordinary comparisons.

>Some may argue that the difference is that negative
>zero is what a very small negative number decays into, and positive zero
>is what a very small positive number decays into.

That is not the way it worked in the B6700 or the DECsystem-10.  So you
have two representations of 0 with identical arithmetic properties.  So
what?  Comparison hardware has to worry, programmers don't.  The VAX
uses (used?) a sign-and-magnitude format, but never generated -0.0 and
regarded the "-0.0" representation as an "illegal operand".

As for IEEE arithmetic, I find that it helps to think of it as having
NO representation for 0.  Instead, it can represent
	-1/epsilon,
	    <negative finite numbers>,
		-epsilon
		<NO zero>
		+epsilon
	    <positive finite numbers>
	+1/epsilon

>My understanding of numbers (no, I'm not an expert at this!)  is that
>zero is only ONE number (basically without sign).  Most numbering
>systems (like two's complement integers) have put in the positive
>domain.

>Programs didn't need to test for
>multiple incantations of zero (which needs to be done with IEEE numbers if
>the hardware doesn't detect BOTH forms).

Should "incantations" be "incarnations"?
If the hardware doesn't process +0 and -0 and process them distinctly,
isn't IEEE.

>As far as I can see, the only good thing (tm) that multiple (+ & -) zeros
>gets you is multiple infinities when you divide by it (which may be the
>object).  As long as both positive and negative numbers exist, and there
>is SOME method of making a bit pattern happen for each of them that are
>defined, it probably doesn't mean much which bits are turned on (use gray
>code, I don't care).  Just make sure that all the operations necessary are
>working, and give proper (documented) results.

I think I should make it clear that when I criticised twos-complement as
silly because it significantly complicates the arithmetic model that the
programmer has to work with, I was not particularly concerned about the
hardware representation of numbers.  To a programmer who "grew up" with
a machine having 48 data bits of which numbers used only 47, it is obvious
that the connection between numbers and bits is only conventional.  (For
example, you could pack 6 EBCDIC characters per word using bit instructions,
but try to do it using integer arithmetic and you were sure of an overflow.)

What I care about is programs running on "hopefully sufficiently large"
machines that turn out _not_ to be "sufficiently large" being quietly
given wrong answers.

There are occasions when Ada 95's modular types are exactly the right thing
to use.  There are many more when plain integer types are right, and I'm
glad that Ada _encourages_ overflow detection.


From ok Mon Feb 19 18:10 EST 1996
Received: (from ok@localhost) by goanna.cs.rmit.EDU.AU (8.7.1/8.6.9) id SAA15322; Mon, 19 Feb 1996 18:10:40 +1100 (EST)
Date: Mon, 19 Feb 1996 18:10:40 +1100 (EST)
From: "Richard A. O'Keefe" <ok>
Message-Id: <199602190710.SAA15322@goanna.cs.rmit.EDU.AU>
To: ok
Subject: follow failed
Content-Type: text
Content-Length: 1504

posted, but mailed to the moderator for approval.

Your response has been saved in ~/dead.letter

Your article follows:
Newsgroups: comp.lang.c.moderated
Subject: Re: But DO C hackers code concisely?
References: <4fa7e7$2pu@solutions.solon.com> <4fst4u$2f1@solutions.solon.com> <4fvh88$e3l@solutions.solon.com>

"Robert F. Monroe" <Robert@hever.demon.co.uk> writes:
>What conceivable use could there be for either printf or scanf in a 
>Windows DLL? The very nature of Windows I/O would cause them to only 
>produce garbage.

Well, the C standard *requires* them.  If you haven't got printf() and
scanf(), you haven't got a "hosted" C implementation. 
	printf(~~1~~)		===	fprintf(stdout, ~~1~~)
and	scanf(~~2~~)		===	fscanf(stdin, ~~2~~)
so the problem is not printf and scanf per se but stdin and stdout, and
if you haven't got _them_ you haven't got a conforming "hosted" C
implementation either.

One very good reason for having them in the library is precisely to catch
code which has been ported to Windows but incompletely.  Since Microsoft C
has exceptions, I would think it appropriate for
	- input from stdin, however expressed
	- output to stdout, however expressed
to raise an exception, and for the library to define printf &c so that user
code cannot accidentally rely on defining them to do something different.
getchar, putchar, printf, scanf, could all share the same few "raise
exception" bytes.

In any case, this is irrelevant to the original example, which used
	sprintf
not printf.


From ok Mon Feb 19 18:17 EST 1996
Received: (from ok@localhost) by goanna.cs.rmit.EDU.AU (8.7.1/8.6.9) id SAA15797; Mon, 19 Feb 1996 18:17:38 +1100 (EST)
Date: Mon, 19 Feb 1996 18:17:38 +1100 (EST)
From: "Richard A. O'Keefe" <ok>
Message-Id: <199602190717.SAA15797@goanna.cs.rmit.EDU.AU>
To: ok
Subject: follow failed
Content-Type: text
Content-Length: 1348

posted, but mailed to the moderator for approval.

Your response has been saved in ~/dead.letter

Your article follows:
Newsgroups: comp.lang.c.moderated
Subject: Re: But DO C hackers code concisely?
References: <4fa7e7$2pu@solutions.solon.com> <4fst4u$2f1@solutions.solon.com>

I gave the example of complex code that could have been replaced by
tiny calls to sprintf.

Michael Smith <msmith@mpx.com.au> writes:
>Yes I do think that MS leaving these functions out is realy stupid,
>but you have to work with the tools you have.

This doesn't in the least spoil my argument.  Assume that leaving the
printf() and scanf() _families_ out of the library used with DLLs is a
good decision, and ignoring wsprintf(),
(a) This wasn't a DLL, it was a complete program.
(b) Converting integers from binary to text is pretty useful.  If sprintf()
    is not available, or if efficiency is a concern and sprintf() proves slow,
    the answer is to write functions

	struct Integer_Format {
	    unsigned char base;	/* 2, 8, 10, 16 */
	    unsigned char pad ;
	    unsigned char width; /* a minimum value */
	};
	static const struct Integer_Format plain = {10, ' ', 1};

	ltostr(char *buf, long val, struct Integer_Format *);
	ultostr(char *buf, unsigned long val, struct Integer_Format *);

    or something similar, and stick them in your personal library.


-- 
Election time; but how to get Labour _out_ without letting Liberal _in_?
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.

Re: Hungarian notation - whoops!

[Lawrence Kirby]

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
-----------------------------------------

Re: Hungarian notation - whoops!

[Kazimir Kylheku]

In article <4g9255$74s@goanna.cs.rmit.EDU.AU>,
Richard A. O'Keefe <ok@goanna.cs.rmit.EDU.AU> wrote:
 >It so happens that the C standard was carefully crafted to allow
 >2s complement, 1s complement, AND sign-and-magnitude.
 >
 >I wrote:
 >    But the fact that abs(x) may deliver a negative
 >    number is something I have to live with the whole time.

It does so for the largest negative value. This is documented. Unfortunately,
as you claim, you do have to check that yourself. And of course, to know what
the largest negative value is, you can use the standard #defined manifest
constants. It's not like abs() returns a negative value for any old random
input. The fact of the matter is that the additive inverse of the largest
negative value under two's complement simply can't be represented in a two's
complement word of the same size, yet the return value from abs() is a signed
quantity. Shrug.

I hear what you are saying though.

 >Kazimir Kyheku again completely misses the point by a country mile.
 >
 >>Not true. If you use the unsigned type, there is no such thing as overflow.
 >>It's called residue math. No operation between two unsigned numbers yields 
 >>undefined results. The "X % Y" operation between unsigned numbers gives you the
 >>smallest positive residue of X with respect to Y. Nothing undefined or
 >>overflown about that. 
 >
 >Kazimir, you will get a LOT further in life if you realise that people who
 >disagree with you sometimes know what they are talking about.
 >
 >The abs function in C is defined by the standard to take SIGNED int as
 >parameter and deliver SIGNED int as result.  I am not claiming now, did

You can cast it to an unsigned type. From K&R2 (A6.2):

	Any integer is converted to a given unsigned type by finding the 
	smallest non-negative value that is congruent to that integer,
	modulo one more than the largest value that can be represented
	in the unsigned type. In a two's complement representation,
	this is equivalent to left-truncation if the bit pattern of the
	unsigned type is narrower, and to zero-filling unsigned values
	and sign-extending signed values if the unsigned type is wider.

If the unsigned type you convert to is the same size as the signed return type
from abs(), you will catch the the right absolute value in the conversion to
unsigned without invoking undefined, or implementation-defined behavior.  If
the unsigned type is wider, of course, the sign extension will mess you up!
And this does not address the "-x" problem, to which there is no solution
under two's complement arithmetic.

 >pointers to get unsigned.  I kid you not.)  By the way, "X % 0" is still
 >undefined in unsigned arithmetic, so the claim that there is "nothing
 >undefined" about it is not true.

That goes without saying.

 >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.

For _one_ legal input. :)

 >Now, it so happens that a C compiler _is_ free to generate overflow checks
 >for signed integer arithmetic, so a twos-complement implementation COULD
 >guarantee "correct result or exception in all cases".  This is occasionally
 >done for Pascal compilers.  I have access to three C compilers (lcc, gcc,
 >and SPARCompiler cc) and if any of them has an option to check that signed
 >arithmetic is done correctly I would be most grateful to be told what it is.
 >
 >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.
 >
 >>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.

I didn't say that it wasn't. But the Ada compiler has to also do a little
``code explosion'' to ensure the same portability as your C with programmer
inserted masking.

 >More importantly, while overflow in signed arithmetic is a run-time error,
 >unsigned arithmetic is very often a design-time error.
 >
 >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.  There is

True.

 >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.
 >
 >Overflows aren't the problem.  Restricted machine arithmetic is the problem.

Not much you can do about the machine, as a programmer and  supporting
multi-precision arithmetic in any language imposes a lot of overhead and code
explosion. The C standard does give you a minimum maximum unsigned integer of
2^32-1. If you need a counter that has more precision, you can use more such
numbers. That it's a pain and inconvenience, I will not deny. I also won't deny
that it will give poor performance on a machine where higher precision
quantities can be directly manipulated. Hence we have C progams littered with
#ifdefs.

Ideally, you should be able to specify in a program the expected range for an
integer, so that the compiler will either fail to translate, or generate the
extra arithmetic code for maintaining the given precision. That sort of goes
against the spirt of C, which is that operations are usually implemented
using suitable idioms of the target architecture. It seems that this philosophy
is ultimately the source of your (and other people's) understandable
frustrations. 

 >>You need unaligned access if you want to have packed character arrays.
 >
 >Sorry, but this simply isn't true.  It may surprise you to know that Pascal

You are right. I don't know why I wrote that, when later on I clearly
contradicted that by saying that such access can be emulated with inline code,
so you don't need the addressability or unaligned access at the hardware level.
Let the second statement be taken as official. 

BTW do you have some sort of specific gripe with two's complement
representations of integer arithmetic?
--