home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!nwnexus!ole!rwing!fnx!nazgul!bright
- From: bright@nazgul.UUCP (Walter Bright)
- Newsgroups: comp.os.os2.programmer
- Subject: SHORT, USHORT, and other absurdities
- Message-ID: <910@nazgul.UUCP>
- Date: 22 Aug 92 01:36:40 GMT
- References: <1992Aug10.162757.13720@thyme.jpl.nasa.gov> <19920811.003756.988@almaden.ibm.com>
- Reply-To: bright@nazgul.UUCP (Walter Bright)
- Organization: Zortech, Seattle
- Lines: 34
-
- In <1992Aug10.162757.13720@thyme.jpl.nasa.gov> Kaleb Keithley writes:
- /Question 1: Given the following code fragment...
- /MRESULT EXPENTRY ClientWndProc (
- / HWND hwnd,
- / USHORT msg,
- ^^^^^^
- / MPARAM mp1,
- / MPARAM mp2)
-
- 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?
-
- They remind me of the old practice (now discredited, after being discovered
- to be useless) of:
- #define BEGIN {
- #define END }
-
- 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!)
-
- 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?
-
- (P.S. I have running code that compiles and runs on 16 bit DOS, 32 bit
- DOS, 16 and 32 bit OS/2, Windows, Windows NT and 68000 Macintoshes.
- Never have I needed those aliases for the basic types.)
-