home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / std / cplus / 1939 < prev    next >
Encoding:
Text File  |  1992-12-31  |  3.5 KB  |  105 lines
  1. Newsgroups: comp.std.c++
  2. Path: sparky!uunet!gatech!usenet.ins.cwru.edu!agate!dog.ee.lbl.gov!network.ucsd.edu!munnari.oz.au!metro!extro.ucc.su.OZ.AU!maxtal
  3. From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
  4. Subject: Argument matching
  5. Message-ID: <1992Dec31.053242.3376@ucc.su.OZ.AU>
  6. Sender: news@ucc.su.OZ.AU
  7. Nntp-Posting-Host: extro.ucc.su.oz.au
  8. Organization: MAXTAL P/L C/- University Computing Centre, Sydney
  9. Date: Thu, 31 Dec 1992 05:32:42 GMT
  10. Lines: 93
  11.  
  12. I wish to examine the impact on the language of the following
  13. proposal. I'm not suggesting this proposal be adopted.
  14.  
  15. Proposal: 
  16.  
  17. 1) for the purposes of computing the signature of a function,
  18. the symbols 'const', 'volatile' and any trailing '&' are ignored.
  19.  
  20. Thus, all the following functions have the same signature:
  21.  
  22.     void f(int);
  23.     void f(const int);
  24.     void f(volatile int);
  25.     void f(const volatile int);
  26.     void f(int&);
  27.     void f(const int&);
  28.     void f(volatile int&);
  29.     void f(const volatile int&);
  30.  
  31. 2) As usually, attempting to define two functions with the same
  32. signature results in a duplicate defintion.
  33.  
  34. 3) For the purpose of overload resolution, the 'type' of
  35. the actual argument is similarly reduced by eliminating
  36. 'const', 'volatile' and '&'.
  37.  
  38. As a consequence, 'trivial' conversions can be ignored during
  39. overload resolution.
  40.  
  41. 4) After a single function has been unambiguously selected
  42. as the best match, then, and only then, are the 
  43. trivial converions considered to determine if the call is legal.
  44.  
  45. For example if 'void f(int&)' is the best match for a call f(3),
  46. it might be determined that an 'lvalue' is required and the call
  47. is illegal. Such considerations are explicitly excluded from
  48. the determination of the best match.
  49.  
  50. 5) In addition, at least the declarations involving call by value
  51. totally ignore the 'const' or 'volatile' specifiers, so that
  52. in the following example, the declaration matches the defintion.
  53.  
  54.     void f(int);
  55.     void f(const int i) { ... }
  56.  
  57. In particular, the 'const' here is not included in the mangled
  58. name because it is not relevant in a adeclaration.
  59. The same rule should apply to the return of values I believe.
  60.  
  61. Principal Consequence.
  62. ---------------------
  63.  
  64. It is not possible to use the 'lvalue'ness of an argument
  65. for matching purposes, and it is not possible to define two functions
  66.  
  67.     f(int);
  68.     f(int&);
  69.  
  70. one of which might modify its argument and one of which wont.
  71. I believe this is correct: if two such functions are desired,
  72. their semantics are different, and they should be given
  73. different names, so that the semantics of the program
  74. are explicit.
  75.  
  76. The modified language continues to support families of
  77. functions with the same name operating on different types
  78.  
  79.     sin(int);
  80.     sin(float);
  81.     sin(complex);
  82.  
  83. which are intended to have similar semantics so that transparency
  84. is desirable. It also supports accidental overloading:
  85.  
  86.     draw(gun);
  87.     draw(picture);
  88.  
  89. where context may indicate the meaning, and which it is desirable to allow
  90. for pragmatic reasons.
  91.  
  92. There is no question that this proposal will break many C++ programs.
  93. It is intended to. The claim is these programs are poorly designed,
  94. and are better off rewritten. (breaking C++ programs is of much
  95. less importance than breaking C ones IMHO. No C programs should be
  96. broken by the above modifications I think.)
  97.  
  98. Comments?
  99.  
  100. -- 
  101. ;----------------------------------------------------------------------
  102.         JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
  103.     Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
  104. ;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
  105.