home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / os / os2 / programm / 4584 < prev    next >
Encoding:
Internet Message Format  |  1992-08-30  |  4.5 KB
  1. Path: sparky!uunet!pilchuck!fnx!nazgul!bright
  2. From: bright@nazgul.UUCP (Walter Bright)
  3. Newsgroups: comp.os.os2.programmer
  4. Subject: Re: SHORT, USHORT, and other absurdities
  5. Message-ID: <912@nazgul.UUCP>
  6. Date: 30 Aug 92 05:09:53 GMT
  7. References: <1992Aug10.162757.13720@thyme.jpl.nasa.gov> <19920811.003756.988@almaden.ibm.com> <910@nazgul.UUCP> <1992Aug24.201535.27997@njitgw.njit.edu>
  8. Reply-To: bright@nazgul.UUCP (Walter Bright)
  9. Organization: Zortech, Seattle
  10. Lines: 81
  11.  
  12. In article <1992Aug24.201535.27997@njitgw.njit.edu> dic5340@hertz.njit.edu (David Charlap) writes:
  13. /In article <910@nazgul.UUCP> bright@nazgul.UUCP (Walter Bright) writes:
  14. />I've never understood this strange urge to #define the basic types. 
  15. />Is anyone out there using a compiler where USHORT would be anything
  16. />other than "unsigned short"? How about SHORT being anything other
  17. />than short, or LONG being anything other than long?
  18. /Because the C types: short, long, and int are not fixed in size.  int
  19. /is simply the machine word, long is double that, and short is
  20. /(usually) int.  By aliassing, them, your program can assume the size.
  21. /SHORT is always 2 bytes, LONG is always four.  If you go to a system
  22. /whose machine word is 4 bytes, then the headers will simply define
  23. /SHORT as an array of 2 chars, LONG as an int, and there will be a new
  24. /type for the long.
  25.  
  26. Perhaps. But that isn't the way it works in practice. SHORT is used as
  27. if arithmetic is allowed on it, and char[2] can't handle arithmetic
  28. operations. The PM and Windows header files excessively and inconsistently
  29. use the typedefs to the point where they are pretty well useless.
  30. If you mean SHORT to be "exactly 16 bits, no more, no less" then it must
  31. be documented so, or your users will assume it means "short", and will use
  32. it such. When lots of code assumes SHORT means "short", then you cannot
  33. change it to mean anything else. A superior approach is to typedef at a
  34. higher level of abstraction, as in:
  35.     typedef int WINDOW_HANDLE;
  36. Then WINDOW_HANDLE could later be typedef'd to be an int, short, double,
  37. struct, void*, etc., and if you were consistent then user code only needs
  38. recompiling. No such luck with SHORT.
  39.  
  40. Your code is not portable between 16 and 32 bit OS/2 anyway. IBM completely
  41. changed the API.
  42.  
  43. /Etc.  In some cases, it's not necessary (although char doesn't have to
  44. /be one byte - especially in a double-byte-character OS, so CHAR is
  45. /defines as the character size, and BYTE is a byte), but all base types
  46. /are redefined to make the code more readable.
  47.  
  48. A double byte character OS is much more likely to use wchar_t, not char.
  49. Too much code depends on char being a byte. Windows NT is a unicode OS,
  50. but a char is still a char. I take issue with your statement that
  51. SHORT as short makes it more readable, *especially* if somebody redefines
  52. SHORT to be something other than short!
  53.  
  54. />These silly typedefs create a useless layer of obfuscation and another
  55. />potential source of error (I always have to check if SHORT really was
  56. />short!)
  57. /Why?  All OS/2 programs use these types.  The point is that short may
  58. /not be 2 bytes on your hardware.  SHORT will always be.
  59.  
  60. Well, not my OS/2 programs. And I have the same code running on 16 and
  61. 32 bit OS/2. In fact, I compared the API's of 16 and 32 bit OS/2, and wrote
  62. my own .h file for it which used things like "int" for sizes that changed.
  63. The IBM .h files used "SHORT" for the 16 bit version and "LONG" for the
  64. 32 bit one. Ugh. I changed that to "int". No #ifdef's!
  65.  
  66. />Another brain-dead one is:
  67. />    #define FAR far
  68. />The argument I hear is that on systems without far, you can just do:
  69. />    #define FAR
  70. />and it goes away! True, but why cannot one do:
  71. />    #define far
  72. />and achieve just as much portability?
  73. /Some DOS compilers don't use "far", but "_far" or "___far" or other
  74. /such things.  Why make your code use #ifdefs for each one of thse.
  75. /It's far (pun intended) easier to write your code with "FAR" and let
  76. /the header translate to what your compiler expects.
  77.  
  78. You could still write everything with "far", and if your compiler supported
  79. "__far" instead, you could:
  80.     #define far __far
  81. You haven't gained anything with FAR.
  82.  
  83. /The OS/2 headers attempt to make code independant of machine word
  84. /sizes, which C does not do.
  85. /Oddly enough, they never defined a MESSAGE type - messages still use
  86. /USHORT or ULONG as their type.
  87.  
  88. Making code independent of word sizes is best accomplished by typedef'ng
  89. at the MESSAGE level, not at the SHORT or LONG level. I submit that 90%
  90. of programs that scrupulously use SHORT and LONG typedefs will have to
  91. be carefully gone through and adjusted if SHORT/LONG are *ever* set to
  92. anything other than short/long.
  93.