home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / cplus / 11678 < prev    next >
Encoding:
Text File  |  1992-07-28  |  2.9 KB  |  63 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!world!wmm
  3. From: wmm@world.std.com (William M Miller)
  4. Subject: Re: Handling of operator . proposal
  5. Message-ID: <BryIM5.KFH@world.std.com>
  6. Organization: Software Emancipation Technology, Inc.
  7. References: <Bqs38H.4L9@taligent.com> <1070008@speedy.CND.HP.COM>
  8. Date: Sat, 25 Jul 1992 18:13:16 GMT
  9. Lines: 52
  10.  
  11. In article <1070008@speedy.CND.HP.COM>, Darren Smith writes:
  12. > [ Side note:  Is that last statement really truly?  If I do something
  13. > like (*anobject).member, the offset to member will be evaluated at
  14. > comile time, but the actual location in memory is determined at
  15. > runtime. ]
  16.  
  17. It's the "*anobject" that's evaluated at runtime; once that's done,
  18. the processing is exactly the same as if you had used the name of a
  19. static or auto object to the left of ".".
  20.  
  21. > The argument that operator.() is only a syntactic operation is
  22. > essentially a meaningless, though true, statement.  The question is:
  23. > is there a good reason that it should remain so?
  24.  
  25. The issue is one of analogy -- all the currently overloadable
  26. operators have a runtime component in the builtin version.  Adding
  27. runtime behavior to an operator that doesn't have it now would be a
  28. completely new thing.
  29.  
  30. In the expression "expr.member", the entire runtime component is in
  31. the evaluation of "expr", not in the ".".  To add smart references in
  32. a way that is consistent with the current language would mean changing
  33. how "expr" is evaluated, not what "." means.  That's the basis of both
  34. the alternative ideas I mentioned in comp.std.c++ a few days ago --
  35. using either delegation via pointer or conversion to reference to
  36. convert "expr" into a reference to the target class.
  37.  
  38. > Also, saying that operator.() is only a syntactic operation, says that
  39. > you will never support *any* proposal that makes operator.() overloadable
  40. > in a way that requires a runtime decision (I can envision a scheme that
  41. > could work at compile time only).
  42.  
  43. This is too strong.  I don't view the "operatorizing" of "." to be a
  44. fatal flaw in this proposal, just one that reduces its attractiveness
  45. and must therefore be weighed with its other pros and cons.
  46.  
  47. > If that is truly your position, then
  48. > make that a separate argument from a critique of a given proposal.  That
  49. > way people can understand better your position, which is not that a
  50. > given proposal is bad, but that all proposals for overloading operator.()
  51. > are bad.
  52.  
  53. I have said that I would prefer a smart-reference proposal that does
  54. not involve operator.() to one that does involve operator.(), all
  55. other things being equal.  The problem is that they never are.  If the
  56. other pending non-operator.() approaches prove to be more problematic
  57. than the best operator.() proposal, I would support the latter.  In
  58. the meantime, however, as Jim has pointed out, his is the most
  59. fully-developed proposal around right now, hence it seemed appropriate
  60. to direct my concerns at it specifically rather than at the generic
  61. concept.
  62.  
  63.