TITLE: Use of const with caches

[ This is part of a discussion that concerns supplying "access methods"
  to private/protected variables. -adc ]

PROBLEM: kanze@us-es.sel.de (James Kanze), 15 Jul 92

In article <1992Jul15.031111.1032@ucc.su.OZ.AU>, maxtal@extro.ucc.su.OZ.AU (John (MAX) Skaller) writes:
|> In article <13v308INNihk@early-bird.think.com> barmar@think.com (Barry Margolin) writes:
|> >In article <1992Jul14.120808.8398@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John (MAX) Skaller) writes:
|> >>	I would claim that
|> >>
|> >>	1) private variable, public get and set routines
|> >>	2) public variable
|> >>
|> >>	have the same interface.(Except for syntactic sugar).
|> >>	
|> >>	Changing the respresentation is not possible in either case.
|> >>	In case 1, the existence of the variable is implied.
|> >
    [discussion over use of complex class deleted...]

|> >>	At best, in case 1 you can do things like hook in
|> >>	debugging statements or do some efficiency improvers
|> >>	not affecting the semantics. (Like managing a cache)
|> >
|> >These are not insiginificant features.  Many programs have been enhanced
|> >quite a bit by addition of caches.
|> 
|> 	I agree. This is a GOOD reason.
|> >
|> >>	If you changed it so the get nd set in case 1 did not
|> >>	merely get and set a variable, either you would be
|> >>	adding complications (as above perhaps for efficiency)
|> >>	or you would be CHANGING the semantics.
|> >>
|> >>	In that case you would WANT to be forced to change
|> >>	all the references to the class, since it is no
|> >>	longer the same class.
|> >
|> >Why would you want to change all the clients just because you've decided to
|> >add a cache, change from polar to rectangular representation, or whatever?
|> 
|> 	You wouldn't. The cache is a good argument not to have public
|> variables. BUT, the following is equivalent to a public variable:
|> 
|> 	wages& Wages();
|> 
|> so you can write
|> 
|> 	Wages()=100;
|> 	if(Wages()<200)resign();
|> 
|> and this 
|> 
|> 	1)Has the same syntax for reading the variable as a get function.
|> 	2)Allows caching
|> 	3)For write access STILL insists that there is such a variable.

But this doesn't work.

To maintain cache coherency, you normally have to know when the
variable has been written in order to maintain consistancy.

When an access function returns a non-const reference, you don't know
what the user does with it.

He may just read.  This is no problem.

He may write.  In this case, you probably have some extra work (flush
the cache, mark buffer as dirty, etc.)

He may take the address, then come back and write to it after having
done several other reads and writes.  In this case, there's no polite
way of saying where you are.  (Think of what happens if your class
represents a file on disk, and the reference is to a part of the file
in an in memory buffer.)

IMHO, it is always an error for a member function to return a non-const
reference to part of the object.  The only exceptions I normally allow
are overloaded operators which return an l-value, and in some special
cases, casting functions (getting a "const char *" from a String, for
example).