Path: utzoo!utgpu!watserv1!watmath!att!dptg!ulysses!andante!alice!ark
From: ark@alice.UUCP (Andrew Koenig)
Newsgroups: comp.lang.c++
Subject: Re: Assignments to reference variables [ and operator.() ]
Message-ID: <11379@alice.UUCP>
Date: 22 Sep 90 06:53:56 GMT
References: <8445@jarthur.Claremont.EDU> <57570@microsoft.UUCP> <1677@lupine.NCD.COM>
Organization: AT&T Bell Laboratories, Liberty Corner NJ
Lines: 43

In article <1677@lupine.NCD.COM>, rfg@NCD.COM (Ron Guilmette) writes:

> In article <57570@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes:
> >
> >-- Please join me in lobbying the ANSI C++ committee to correct this oversight
> >in the language definition.  Overloading operator.() makes equal sense for
> >reference classes as overloading operator->() for pointer classes...

> Finally, Jim and I have found something to agree on. :-)

> I'd say that Jim is correct is saying that treating either `.' or `->' as
> if they were OPERATORS (kinda like other operators) makes equal sense,
> i.e. *NONE*!  Allowing overloading for either of these makes about as
> much sense as allowing overloading for `{' or `}'.

I can't resist this one.

Of course . and -> aren't operators -- their right `operand' isn't
an expression.  However, one can view . or -> followed by an identifier
as being a postfix unary operator.

That is, writing a.b might be considered as applying the .b postfix
operator to a.  In other words, a.b could in principle be interpreted
as a.operator .b()  .

I think this notation is consistent, at least in principle.  It does,
however, have a few problems:

	1. How does one extend it to the -> symbol?  Is p->b equivalent
	to (*p).operator .b()?  Or is it necessary to define operator->b,
	which would be ambiguous (I think the first case is right)?

	2. It is too easy to confuse operator.b() with operator b().

	3. (perhaps this should be 0.) Is it really necessary?

I'm reluctant to propose new features of this sort because C++ has
enough stuff already, so this is not a proposal.  It's just a sketch
of what it might mean to `overload the . operator' if it were really
necessary to do it.
-- 
				--Andrew Koenig
				  ark@europa.att.com