home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / lang / cplus / 13569 < prev    next >
Encoding:
Internet Message Format  |  1992-09-12  |  2.7 KB

  1. Path: sparky!uunet!news.univie.ac.at!blekul11!frmop11!dearn!esoc!kkeyte
  2. Organisation: European Space Operation Centre (E.S.O.C)
  3. Date: Saturday, 12 Sep 1992 15:05:12 CET
  4. From: Karl Keyte <KKEYTE@ESOC.BITNET>
  5. Message-ID: <92256.150512KKEYTE@ESOC.BITNET>
  6. Newsgroups: comp.lang.c++
  7. Subject: Re: Answers on a postcard...
  8. References: <92254.104002KKEYTE@ESOC.BITNET> <1992Sep10.174914.838@taumet.com>
  9.  <92255.112151KKEYTE@ESOC.BITNET> <1992Sep11.174716.3699@taumet.com>
  10. Lines: 40
  11.  
  12. >>The implication of what you say is that it is not possible to overload
  13. >>operators maintaining the correct functionality of the operator.  This
  14. >>indeed means that precedence in overloaded operators cannot be maintained
  15. >>if all operands are simply passed as arguments to the function implementing
  16. >>the operator functionality and evaluated in a language independent order.
  17. >>Imagine commonly used "chain" operators such as && and ::.
  18. >
  19. >The only other overloadable operator which imposes order of evaluation
  20. >is the comma.  Originally it was not overloadable, since there seemed
  21. >to be no good reason to allow it.  It looks like we have found a
  22. >good reason to disallow it, namely that the implied order of
  23. >evaluation no longer holds.  (Too bad it is so hard to stuff the
  24. >genie back into the bottle.)
  25. >
  26.  
  27. I accept what you're saying but my point is this...  In overloading, for
  28. example, the '+' operator for one of my own classes, I would try to provide
  29. functionality which fits with the usual understanding of the operator.  In
  30. providing '+' for "strings" I would hope to offer concatenation rather than
  31. truncation with the '+' operator.  That works quite well.  If I require
  32. something which is unrelated to any operator I would rather not overload
  33. but provide a member function.  This means, when I overload an operator
  34. it is because I want to perform some function which is similar (in concept)
  35. to the original operator.  I also want the user (programmer) to be able to
  36. use the operator in the usual fashion.
  37.  
  38. To do what I have just described with the comma-operator in C++ is not
  39. possible.  Of course I can overload it to do something completely unrelated
  40. to what one understands of the operator, but to do something "special" and
  41. leave its order of evaluation the same as the operator is not possible.
  42. I feel that this is an oversight rather than expected behaviour.  I can't
  43. find any reference to the specifics of overloading the comma-operator in
  44. any of the reference works, other than that it is possible to overload.
  45.  
  46. You mention that there seems no sensible reason to allow its overloading.  I
  47. see no sensible reason to "disallow" it unless the order of evaluation
  48. problem cannot be rectified, which of course it could.  At present I feel
  49. the situation is not clear enough in this area.
  50.  
  51. Karl
  52.