home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / cplus / 11512 < prev    next >
Encoding:
Internet Message Format  |  1992-07-25  |  2.6 KB
  1. From: dds@speedy.CND.HP.COM (Darren Smith)
  2. Date: Fri, 24 Jul 1992 23:41:19 GMT
  3. Subject: Re: Handling of operator . proposal
  4. Message-ID: <1070008@speedy.CND.HP.COM>
  5. Organization: HP Network and System Management Division
  6. Path: sparky!uunet!usc!sdd.hp.com!hpscdc!hplextra!hpfcso!hpcnd!speedy!dds
  7. Newsgroups: comp.lang.c++
  8. References: <Bqs38H.4L9@taligent.com>
  9. Lines: 44
  10.  
  11. |   "." is only an operator in the sense that "::" is, i.e., syntactically;
  12. |   it's not a run-time operation, like all the currently-overloadable
  13. |   operators are.
  14.  
  15. It is true that operator. is *currently* only a syntactic operation,
  16. and not a run-time operation.  Why can't it be both?
  17.  
  18. Here's an analogy for you: function calls.  In both C and C++, you can
  19. make function calls that are resolved at compile time (OK.  technically
  20. at load time.  Never-the-less, not at runtime).  This is sufficient for
  21. most uses, and is all that some languages offer.  However, we also
  22. have these things called "function pointers", that allow you to
  23. determine which function to call at runtime.  Yes, the syntax is slightly
  24. different from regular function calls, so this is not a perfect analogy.
  25. However, I think this is largely because of the history of "C".  The
  26. concept of being able to do something at runtime that most of the time
  27. can be determined at compile or load time is not unprecedented in the
  28. language.  The operator.() proposal essentially allows you to do
  29. something at runtime that is currently only done at compile time.
  30.  
  31. [ Side note:  Is that last statement really truly?  If I do something
  32. like (*anobject).member, the offset to member will be evaluated at
  33. comile time, but the actual location in memory is determined at
  34. runtime. ]
  35.  
  36. The argument that operator.() is only a syntactic operation is
  37. essentially a meaningless, though true, statement.  The question is:
  38. is there a good reason that it should remain so?  That is the issue
  39. that should be addressed when you say it's not a runtime operation.
  40. What problems are caused by it having the possibility of being a runtime
  41. operation?  Are they solvable?
  42.  
  43. Also, saying that operator.() is only a syntactic operation, says that
  44. you will never support *any* proposal that makes operator.() overloadable
  45. in a way that requires a runtime decision (I can envision a scheme that
  46. could work at compile time only).  If that is truly your position, then
  47. make that a separate argument from a critique of a given proposal.  That
  48. way people can understand better your position, which is not that a
  49. given proposal is bad, but that all proposals for overloading operator.()
  50. are bad.
  51.  
  52. --
  53. Darren Smith     dds@cnd.hp.com     229-2536    Hewlett Packard
  54. --
  55.