home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / std / cplus / 1993 < prev    next >
Encoding:
Text File  |  1993-01-07  |  3.0 KB  |  96 lines
  1. Newsgroups: comp.std.c++
  2. Path: sparky!uunet!taumet!steve
  3. From: steve@taumet.com (Steve Clamage)
  4. Subject: Re: Extra COntant definitions
  5. Message-ID: <1993Jan7.172522.8340@taumet.com>
  6. Organization: TauMetric Corporation
  7. References: <1224@racerx.bridge.COM>
  8. Date: Thu, 7 Jan 1993 17:25:22 GMT
  9. Lines: 85
  10.  
  11. rodb@racerx.bridge.COM (Rod Burman) writes:
  12.  
  13. >It has just occured to me that since C++ is a strongly typed language
  14. >it should provide intrinsic support for constants of all intrinsic types
  15. >that is currently we have:
  16.  
  17. >        1    // int
  18. >        1U    // unsigned int
  19. >        1L    // long
  20. >        1UL    // unsigned long
  21.  
  22. OK so far.
  23.  
  24. >        '\1'    // unsigned char ...
  25.  
  26. No.  This has type "char", a type distinct from both "signed char" and
  27. "unsigned char".  It will usually have the same implementation as either
  28. signed or unsigned char, you are not allowed to assume which.
  29. Similarly, type int usually has the same implementation as either type
  30. short or type long, but is always a type distinct from both.  Not all
  31. current C++ implementations have the required three character types.
  32.  
  33. >        '\1'L    // wide unsigned char ...
  34.  
  35. No.  It will have whatever type the implementation chose for wide
  36. characters, and may be any signed or unsigned integral type.  There
  37. is no "signed wide character" or "unsigned wide character" type, just
  38. plain "wide character", which may behave as either a signed or an
  39. unsigned type.
  40.  
  41. >        "\1"    // unsigned char[]
  42. >        "\1"L    // unsigned wide char  ...
  43.  
  44. No to both.  See above.
  45.  
  46. >This as I see it leaves room for:
  47.  
  48. >        1S    // short
  49. >        1US    // unsigned short
  50.  
  51. ... etc.
  52.  
  53. >Ofcourse you can always have:
  54.  
  55. >    (short) 1;    // etc
  56.  
  57. >and this may be more portable ...
  58.  
  59. Well, I would say it is more general, rather than more portable.
  60.  
  61. You could make a symmetry argument for the additional suffixes, but
  62. I don't see that they solve any problem.  Although this would not
  63. break any existing code, it might create readability problems.
  64.  
  65. For example, I don't like using the lower-case 'l' suffix, since 2l
  66. looks too much like 21.  Similarly, some type faces make 'S' or 's'
  67. hard to distinguish at a glance from a '5', particularly when you
  68. are not expecting to see the letter 's'.
  69.  
  70. Whenever a short value appears in an expression it is immediately
  71. promoted to type int.  For example, let XX stand for any integer
  72. literal representable as a short, and XXs be that value with type
  73. short as you request.  Let Z be a value of any scalar type.  Then
  74. the three expressions
  75.     XX + Z
  76.     (short)XX + Z
  77.     XXs + Z
  78. must always have exactly the same effect.  The 's' suffix does not
  79. allow the compiler to take any shortcuts it could not take without
  80. the suffix.  (The suffix can only be applied to a literal, so the
  81. compiler already knows whether the value is representable as a short.)
  82.  
  83. The only place a "short" suffix could make a difference is in
  84. choosing an overloaded function:
  85.     int foo(int);
  86.     int foo(short);
  87.     ...
  88.     foo(XX)        // calls foo(int)
  89.     foo(XXs)    // calls foo(short)
  90. Of course, we can always write
  91.     foo((short)XX)    // calls foo(short)
  92. for the rare cases when this arises.
  93. -- 
  94.  
  95. Steve Clamage, TauMetric Corp, steve@taumet.com
  96.