home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / lang / cplus / 13537 < prev    next >
Encoding:
Text File  |  1992-09-11  |  2.8 KB  |  61 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!taumet!steve
  3. From: steve@taumet.com (Steve Clamage)
  4. Subject: Re: Answers on a postcard...
  5. Message-ID: <1992Sep11.174716.3699@taumet.com>
  6. Organization: TauMetric Corporation
  7. References: <92254.104002KKEYTE@ESOC.BITNET> <1992Sep10.174914.838@taumet.com> <92255.112151KKEYTE@ESOC.BITNET>
  8. Date: Fri, 11 Sep 1992 17:47:16 GMT
  9. Lines: 50
  10.  
  11. Karl Keyte <KKEYTE@ESOC.BITNET> writes:
  12.  
  13. >>In the expression in parens, it is unspecified whether "x=1" or
  14. >>"x+1" is evaluated first.  They are arguments to the "operator,()"
  15. >>function, not the left and right side of a comma-expression.  If
  16. >>"x+1" is evaluated first, which is legal, it will use an
  17. >>uninitialized "x.value".
  18.  
  19. >The implication of what you say is that it is not possible to overload
  20. >operators maintaining the correct functionality of the operator.  This
  21. >indeed means that precedence in overloaded operators cannot be maintained
  22. >if all operands are simply passed as arguments to the function implementing
  23. >the operator functionality and evaluated in a language independent order.
  24. >Imagine commonly used "chain" operators such as && and ║║.
  25.  
  26. First, precedence and order of evaluation are different concepts.
  27. In the expression
  28.     a + b * c
  29. (where a, b, and c may themselves be parenthesized expressions)
  30. fixed precedence means the expression is always equivalent to
  31.     a + (b * c)
  32. independent of operator overloading.  Overloading does not change
  33. precedence.  You still do not know which of 'a', 'b', and 'c' is
  34. evaluated first and which is evaluated last.  You also do not
  35. know whether 'a' is evaluated before or after the '*' operation
  36. is performed.  Within the limits of precedence, the order of
  37. evaluation is unspecified.  Precedence does require that '*'
  38. be performed before '+', since '+' requires the result of '*'.
  39.  
  40. Second, what is the "correct" functionality of an overloaded operator?
  41. The language imposes no restrictions on the semantics of overloaded
  42. operators (except for ->).  You could define "&&" to do literally
  43. anything; it need not be any sort of logical "and".
  44.  
  45. The non-overloaded && and || enforce an order of evaluation because
  46. their value can be potentially be known without evaluating the
  47. second operand.  The conditional evaluation makes for compact
  48. expressions.  An overloaded operator && or || cannot be assumed
  49. to have such behavior, and both operands must always be evaluated.
  50.  
  51. The only other overloadable operator which imposes order of evaluation
  52. is the comma.  Originally it was not overloadable, since there seemed
  53. to be no good reason to allow it.  It looks like we have found a
  54. good reason to disallow it, namely that the implied order of
  55. evaluation no longer holds.  (Too bad it is so hard to stuff the
  56. genie back into the bottle.)
  57. -- 
  58.  
  59. Steve Clamage, TauMetric Corp, steve@taumet.com
  60. Vice Chair, ANSI C++ Committee, X3J16
  61.