Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!jarthur!dfoster
From: dfoster@jarthur.Claremont.EDU (Derek R. Foster)
Newsgroups: comp.lang.c++
Subject: Re: Assignments to reference variables [ and operator.() ]
Message-ID: <8754@jarthur.Claremont.EDU>
Date: 30 Sep 90 06:16:17 GMT
References: <8445@jarthur.Claremont.EDU> <57570@microsoft.UUCP> <1677@lupine.NCD.COM> <57684@microsoft.UUCP> <3833@osc.COM>
Organization: Harvey Mudd College, Claremont, CA 91711
Lines: 46

In article <3833@osc.COM> tma@osc.UUCP (Tim Atkins) writes:
>
>	As I see it there is a very pragmatic reason for not allowing
>	operator . in C++.  Namely that it would be very difficult to
>	distinquish normal use from the redefined use.
> [example deleted for brevity]
>	I see no sane way to get back to the original operator . meaning
>	in the above case.  Any takers?

You might be able to use the global scope operator :: before the operator .
when its use was ambiguous. i.e. 

  object ::. member

or, more verbosely,

  object ::operator. member

I'm fairly certain the second is legal syntax. I'm not sure about the first.
If a redefined version of operator.() existed, it would of course always
override the default definition unless the global scope operator was
specifically used.

Just a side note about my letter which sparked this whole controversy:
About the second or third option I tried in my search for a way to
make my code work/look clean was the one of creating a "reference to
variable" class, as a latter poster suggested. I still think that this would
be a reasonable way to solve my problem, except for one minor detail: it
doesn't work. As this same later poster pointed out, this basically can't
be done due to C++'s inability to overload '.' It was nonetheless one of
the first things I tried, and I was quite surprised to find out that it
couldn't be done. This fact alone says something about the subject, I
think. Refusing to allow operator.() to be overloaded seems an arbitrary
restriction on the language, and forces programmers like me into
very convoluted syntax to get around its absence. The lack of this function
made me have to convert every reference to an object into pointer syntax,
adding perhaps forty extra sets of (* ) into my program for no good reason,
not to mention introducing some nasty bugs in the process. (Since the
operator [] can be applied to a pointer to an object as well as to the
object itself, any place where I forgot to phrase it as (*object)[] and
instead just wrote object[] produced no compiler error, just some highly
creative and sometimes very subtle results at runtime.) I wholeheartedly
support adding overloading of operator.() to the language! Let's do it,
folks!

Derek Riippa Foster