Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!cs.utexas.edu!uunet!futures!saxony!dgil
From: dgil@pa.reuter.COM (Dave Gillett)
Newsgroups: comp.lang.c++
Subject: Re: Overloaded operator dot?
Message-ID: <837@saxony.pa.reuter.COM>
Date: 25 Mar 91 21:53:27 GMT
References: <11152@jarthur.Claremont.EDU> <624@taumet.com> <12193@pasteur.Berkeley.EDU> <1991Mar21.032937.16534@world.std.com>
Distribution: na
Organization: Reuter:file Inc  (A Reuter Company) Palo Alto, CA
Lines: 32

In <1991Mar21.032937.16534@world.std.com> wmm@world.std.com (William M Miller) writes:

>jbuck@galileo.berkeley.edu (Joe Buck) writes:
>> |> Q3. What functionality will be added to the language which is not now
>> |>     conveniently available?  (What problem does this solve?)

>That doesn't answer the question -- all you've done is to give the new
>feature a name.  The real issue is whether the technique solves any major
>problems that can only be addressed awkwardly or not at all in the existing
>language.  In other words, give some specific applications that demonstrate
>that "smart references" aren't just another of the hundreds of nifty ideas
>floating around that are cute and interesting but don't really expand the
>power of the language to address real-world problems.


     Without the facility to overload operator., one must resort to code like

                 (&f)->thing

to get the equivalent, and overload operator->.  Without overloading of 
operator->, we know that this is equivalent to writing

                 f.thing

and it would be "really really nice" (i.e. highly desirable) to be able to
guarantee to users of a class that this equivalence holds, even if the
operators are overloaded.  [i.e.  I would prefer that for any class where
operator-> is overloaded, operator. would be overloaded to preserve this
equivalence; leave it up to the user of the class whether they want to use
an f or an f*.]

                                              Dave