Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!usc!apple!netcom!sjsumcs!horstman
From: horstman@mathcs.sjsu.edu (Cay Horstmann)
Newsgroups: comp.lang.c++
Subject: Re: Overloaded operator dot?
Message-ID: <1991Mar17.184122.717@mathcs.sjsu.edu>
Date: 17 Mar 91 18:41:22 GMT
References: <11152@jarthur.Claremont.EDU> <624@taumet.com>
Organization: San Jose State University - Math/CS Dept.
Lines: 24

In article <624@taumet.com> steve@taumet.com (Stephen Clamage) writes:
>
>In particular, you would not define both operator dot and operator arrow
>for the same class.  The result would be unmanageable.  

I don't think that is true at all. First of all, inside a MEMBER FUNCTION
of X (a class with both operators . and -> overloaded), you could still access
the members. That should be sufficient for implementing such very specialized
classes. Furthermore, if X::operator& is not redefined, member access is
still possible through (&x)->m, since -> cannot be overloaded for the pointer
type X*. 

I am NOT saying that operator. should necessarily be overloadable just because
it can be done. Just that the most common argument ("it would be a mess to
access members") doesn't hold water. Just out of curiosity: has the working
group identified any code that would break if operator. overloading was 
permitted? (Stephen cited that as one important task of the working group.)

The most important question is of course: Does it solve any problems? Recently
it was generally agreed that it would be useful for defining an access class
which can be both an lvalue and an rvalue. Is anyone aware of another use for
it?

Cay