Efficient coding considered harmful?

[Knudsen]

In article <1630 at scolex>, seanf at sco.COM (Sean Fagan) writes:
> If I were to look at that, I would say that the coder used a short because
> he/she wanted to document the fact that the value was not expected to
> overflow a short. (is anybody following me?  if so, could you explain it to
> me? 8-)  Here's another shot:)  I.e., "I don't expect the value to be larger
> than 32k-1 [on most 32-bit machines, for example]."  It's what I would do.

What I do for variables whose size I know is limited,
but where I want to retain the efficiency of "int", is:

typedef int sexy;

and then declare such vars as sexy.  This reminds me that these
would fit perfectly well in a byte, but should be computed as int
to avoid the oft-mentioned promotions to int.
It's especially helpful if/when I rewrite a function in assembler,
where the efficiency problem mostly goes away.

If I got terrible strapped for data memory, I could change the
typedef so that sexy was really char.  This would expand and slow
down the code, as others have noted.

Some of you may have guessed I write for the 6809, whose SEX
(sign extend) instruction is the mainstay of promoting
bytes (chars) to 16-bit ints.  Of course most of you are worried
about 16-bit shorts and 32-bit ints, but the principle is the same.
You may call your version "shorty" ... :-)

My 6809 C compiler *is* smart enough to test chars as just one byte
(no SEXing to int), so I typedef'ed "bool" to "char."

BTW, a year ago there was a discussion about typedef'ing all sorts
of custom types, and NEVER using the straight char/short/int/long
types in your own code.  I don't go this far, but I do have
"byte" and "ubyte" and use "char" only for ASCII items;
plus I have some custom "int" types like "index" and "time."
But I use "int" for plain old loop counters and such.
-- 
Mike Knudsen  Bell Labs(AT&T)   att!ihlpl!knudsen
"Lawyers are like nuclear bombs and PClones.  Nobody likes them,
but the other guy's got one, so I better get one too."