Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!asuvax!ukma!aunro!alberta!cpsc.ucalgary.ca!news
From: gintera@fsd.cpsc.ucalgary.ca (Andrew Ginter)
Newsgroups: comp.lang.c++
Subject: Re: Overloaded operator dot?
Summary: same problems as smart ptrs
Message-ID: <1991Mar22.172215.20521@cpsc.ucalgary.ca>
Date: 22 Mar 91 17:22:15 GMT
References: <11152@jarthur.Claremont.EDU> <624@taumet.com> <1991Mar17.184122.717@mathcs.sjsu.edu> <71437@microsoft.UUCP>
Sender: gintera@cpsc.ucalgary.ca (Andrew Ginter)
Organization: U. of Calgary Computer Science
Lines: 69
Nntp-Posting-Host: fsd

In article <71437@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes:
> ... Consider the case of a named object that's huge,
>knows its huge, and thus tries to keep its representation on disc most of
>the time:
>
>Class  TryToBeDiscResident : public ThingsProtocol
>{
>	FileName fileName;	// where to find the object when *its not*
>				// in memory!
>
>	Thing* p;		// where to find the object when *it is* in 
>				// memory!
>public:
>	Thing& operator.();
>	....
>};
>
>Thing& TryToBeDiscResident::operator.()
>{
>	if (p == NULL)
>	{
>		p = GoGetThingFrom(fileName);
>	}
>
>	return *p;
>
>}
>
>[I'll leave it to the reader to decide when and how Things that 
>TryToBeDiscResident take themselves back out of memory and onto disc.]

This implementation of an overloaded "dot" operator may be ultimately
useful.  I'm not arguing that point.  A straightforward implementation
of such an overloading mechanism however, in the style of existing
support for smart pointers, will suffer from the same serious flaws
that existing smart pointer support suffers.  Taking your example, a
programmer may wish to write something which appears perfectly
reasonable:

     int do_stuff ();
     X.a = do_stuff ();

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.  

This problem and similar problems which arise in smart pointers can be
solved by further modifying the language definition to correct these
order of evaluation problems.  For a detailed discussion of this
problem and its solution, see my technical report No. 91/417/01.  The
report is available as the compressed ".dvi" file 

  DUA3:[ANONYMOUS.PUB.TECH]CPSC-91-417-01-DVI.Z

from ucnet.ucalgary.ca.  Hard copies can be ordered from the CS dept
at (403) 220-6015.

Andrew Ginter, 403-220-6320, gintera@cpsc.ucalgary.ca