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