Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!uunet!microsoft!jimad
From: jimad@microsoft.UUCP (Jim ADCOCK)
Newsgroups: comp.lang.c++
Subject: Re: Overloaded operator dot?
Message-ID: <71572@microsoft.UUCP>
Date: 28 Mar 91 20:04:25 GMT
References: <11152@jarthur.Claremont.EDU> <624@taumet.com> <1991Mar17.184122.717@mathcs.sjsu.edu> <71437@microsoft.UUCP> <1991Mar22.172215.20521@cpsc.ucalgary.ca>
Reply-To: jimad@microsoft.UUCP (Jim ADCOCK)
Organization: Microsoft Corp., Redmond WA
Lines: 55

In article <1991Mar22.172215.20521@cpsc.ucalgary.ca> gintera@fsd.cpsc.ucalgary.ca (Andrew Ginter) writes:

|The current C++ language definition does not define the order of
|evaluation of the assignment expression.  If the LHS is evaluated
|first, the Thing to which X refers is brought into memory (if it
|wasn't there already) and the emitted code may obtain a pointer to the
|"a" element in this thing.  The intent being that the RHS would then
|be evaluated and the result assigned to "X.a" through this pointer
|which was perhaps stored in a processor register across the call to
|do_stuff.
|
|The problem with this expression is that do_stuff may do something
|which causes the Thing to which X refers to be flushed back to disk.
|The subsequent assignment through the stored pointer does not update
|the disk-resident Thing, it updates the memory the Thing used to
|occupy.  

Like I said, I leave it to the reader to determine when a good time
to flush X back to disk.

One strategy for when to flush back to disk is to wait till program
termination.  In which case the overloaded operator dot is being
used to implement a deferred load.  [See Wirth's comments regards
deferred loading in the Oberon System, for example]

----

Again, the problem I see is that when I or others post short, acedemic
examples of using operator dot, people attack the examples as being
acedemic, whereas if we generalize the use of operator dot and call
that generalization "smart references" then people accuse us of
applying a name to a "non-problem."

Really, the only significant difference between overloaded operator dot and
operator-> is the syntax presented to the end user.  If ANSI-C++
committee members consider it a "good thing" for end users to have
to guess whether to use "." or "->" in any given situation, then
overloaded operator-> suffices.  However, if the ANSI-C++ committee 
members consider it a "good thing" that the historical use of "."
be maintained when manipulating values, whereas "->" be used when
manipulating "pointed-to" things, then the committee members should
give us overloaded operator dot so that we can make that distinction --
so that we can use "." when we write classes that act like values, and
we can use "->' when we write classes that act like pointers.

But, if the committee members no longer consider the distinction
between "." and "->" important, then how about removing the distinction 
completely from the language, and let the compiler distinguish from context
which is meant [please note that this is a rhetorical argument :-]

I claim the distinction between values and references remains important
in C++, as does the distinction between "." and "->"

Therefore, the ANSI-C++ committee members ought to give us the necessary
tools to write classes using either syntax.