🚀 go-pugleaf

In article <1992Aug24.201535.27997@njitgw.njit.edu> dic5340@hertz.njit.edu (David Charlap) writes:
/In article <910@nazgul.UUCP> bright@nazgul.UUCP (Walter Bright) writes:
/>I've never understood this strange urge to #define the basic types. 
/>Is anyone out there using a compiler where USHORT would be anything
/>other than "unsigned short"? How about SHORT being anything other
/>than short, or LONG being anything other than long?
/Because the C types: short, long, and int are not fixed in size.  int
/is simply the machine word, long is double that, and short is
/(usually) int.  By aliassing, them, your program can assume the size.
/SHORT is always 2 bytes, LONG is always four.  If you go to a system
/whose machine word is 4 bytes, then the headers will simply define
/SHORT as an array of 2 chars, LONG as an int, and there will be a new
/type for the long.

Perhaps. But that isn't the way it works in practice. SHORT is used as
if arithmetic is allowed on it, and char[2] can't handle arithmetic
operations. The PM and Windows header files excessively and inconsistently
use the typedefs to the point where they are pretty well useless.
If you mean SHORT to be "exactly 16 bits, no more, no less" then it must
be documented so, or your users will assume it means "short", and will use
it such. When lots of code assumes SHORT means "short", then you cannot
change it to mean anything else. A superior approach is to typedef at a
higher level of abstraction, as in:
	typedef int WINDOW_HANDLE;
Then WINDOW_HANDLE could later be typedef'd to be an int, short, double,
struct, void*, etc., and if you were consistent then user code only needs
recompiling. No such luck with SHORT.

Your code is not portable between 16 and 32 bit OS/2 anyway. IBM completely
changed the API.

/Etc.  In some cases, it's not necessary (although char doesn't have to
/be one byte - especially in a double-byte-character OS, so CHAR is
/defines as the character size, and BYTE is a byte), but all base types
/are redefined to make the code more readable.

A double byte character OS is much more likely to use wchar_t, not char.
Too much code depends on char being a byte. Windows NT is a unicode OS,
but a char is still a char. I take issue with your statement that
SHORT as short makes it more readable, *especially* if somebody redefines
SHORT to be something other than short!

/>These silly typedefs create a useless layer of obfuscation and another
/>potential source of error (I always have to check if SHORT really was
/>short!)
/Why?  All OS/2 programs use these types.  The point is that short may
/not be 2 bytes on your hardware.  SHORT will always be.

Well, not my OS/2 programs. And I have the same code running on 16 and
32 bit OS/2. In fact, I compared the API's of 16 and 32 bit OS/2, and wrote
my own .h file for it which used things like "int" for sizes that changed.
The IBM .h files used "SHORT" for the 16 bit version and "LONG" for the
32 bit one. Ugh. I changed that to "int". No #ifdef's!

/>Another brain-dead one is:
/>	#define FAR far
/>The argument I hear is that on systems without far, you can just do:
/>	#define FAR
/>and it goes away! True, but why cannot one do:
/>	#define far
/>and achieve just as much portability?
/Some DOS compilers don't use "far", but "_far" or "___far" or other
/such things.  Why make your code use #ifdefs for each one of thse.
/It's far (pun intended) easier to write your code with "FAR" and let
/the header translate to what your compiler expects.

You could still write everything with "far", and if your compiler supported
"__far" instead, you could:
	#define far __far
You haven't gained anything with FAR.

/The OS/2 headers attempt to make code independant of machine word
/sizes, which C does not do.
/Oddly enough, they never defined a MESSAGE type - messages still use
/USHORT or ULONG as their type.

Making code independent of word sizes is best accomplished by typedef'ng
at the MESSAGE level, not at the SHORT or LONG level. I submit that 90%
of programs that scrupulously use SHORT and LONG typedefs will have to
be carefully gone through and adjusted if SHORT/LONG are *ever* set to
anything other than short/long.