home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / std / cplus / 997 < prev    next >
Encoding:
Internet Message Format  |  1992-07-30  |  2.3 KB

  1. Path: sparky!uunet!sun-barr!news2me.ebay.sun.com!jethro.Corp.Sun.COM!exodus.Eng.Sun.COM!rbbb.Eng.Sun.COM!chased
  2. From: chased@rbbb.Eng.Sun.COM (David Chase)
  3. Newsgroups: comp.std.c++
  4. Subject: Re: Alternatives to operator.()
  5. Date: 30 Jul 1992 21:45:38 GMT
  6. Organization: Sun Microsystems, Mt. View, Ca.
  7. Lines: 32
  8. Message-ID: <l7goo2INNjm8@exodus.Eng.Sun.COM>
  9. References: <1992Jul23.024159.18039@microsoft.com> <BruME9.HGJ@world.std.com> <1992Jul27.204820.8400@microsoft.com> <Bs6n59.GD@world.std.com>
  10. NNTP-Posting-Host: rbbb
  11.  
  12. In article <Bs6n59.GD@world.std.com> wmm@world.std.com (William M Miller) writes:
  13. >The reason I "ignore" this point is because it is irrelevant to the subject
  14. >of the analysis I was making -- that built-in "." is different from built-in
  15. >"->" because the former does not have a corresponding run-time operation,
  16. >while the latter does.  Since the built-in "." has no runtime operation, it
  17. >does not make sense, IMHO, to allow an overloaded operator.(), since
  18. >overloaded operators are primarily runtime operations (calling a function to
  19. >perform some action).  The built-in "->" _does_ perform a runtime operation
  20. >(indirection), so providing an overloaded operator->() does make sense from
  21. >this perspective.
  22.  
  23. I don't want to take any sides in this mudfight, but the preceding
  24. analysis strikes me as particularly bogus.  Without looking at the
  25. assembly language, you don't know what "." or "->" do in terms of
  26. run-time operations.  In different contexts (in C, ignoring C++) they
  27. do different things -- for instance, "&(X -> a)" is not performing an
  28. indirection.  In certain compilation modes (e.g., position independent
  29. code generation) they do different things at run-time.  If you're
  30. interpreting the program, they may do other different things at
  31. run-time.  From my current point of view (head firmly stuffed into the
  32. back-end of a compiler) it all looks like bits, and (after cfront and
  33. cc and the optimizer get through with them) not very attractive bits.
  34.  
  35. So, do please try not to confuse the language specification with the
  36. language implementation/compilation.  (Didn't I say this once already
  37. in a different context?)  If, generally speaking, a proposal isn't a
  38. run-time turkey (a well-defined term, eh?), then it ought to be
  39. evaluated on how well it works with the rest of the language and what
  40. programmers need.
  41.  
  42. David Chase
  43. Sun
  44.