Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uwm.edu!linac!att!ucbvax!pasteur!galileo.berkeley.edu!jbuck
From: jbuck@galileo.berkeley.edu (Joe Buck)
Newsgroups: comp.lang.c++
Subject: Re: Overloaded operator dot?
Message-ID: <12193@pasteur.Berkeley.EDU>
Date: 21 Mar 91 01:42:13 GMT
References: <11152@jarthur.Claremont.EDU> <624@taumet.com>
Sender: news@pasteur.Berkeley.EDU
Reply-To: jbuck@galileo.berkeley.edu (Joe Buck)
Lines: 66

In article <624@taumet.com>, steve@taumet.com (Stephen Clamage) writes:
> The ANSI C++ Committee (X3J16) met from 11-15 March, and the issue of
> overloading the dot operator was discussed.  The working group
> responsible for evaluating extensions to the language presented a summary
> of their deliberations, and concluded that the issue requires more study.

> For any suggested addition or change, an important set of questions:
> Q1. Will any currently-legal programs be affected?
> Q2. What current functionality will be lost?

No and no.  The change has no effect on any working program (but I suppose you
knew that and are just asking the "standard set of questions") since
existing programs call "operator ." a syntax error.

|> Q3. What functionality will be added to the language which is not now
|>     conveniently available?  (What problem does this solve?)

The new functionality is the ability to have "smart references".  The
semantics parallels the semantics for "smart pointers" obtained by overloading
operator -> and should have the same restrictions.

The new text would read

"Class member access using .

	primary-expression . primary-expression

is considered a unary operator.  An expression x.m is interpreted as
(x.operator.()).m for a class object x (here the first "." is the
builtin "." -- perhaps I should write ((&x)->operator.()).m to be
unambiguous).  It follows that operator.() must return either a reference
to a class or an object of, or reference to a class for which
operator.() is defined.  operator.() must be a nonstatic member function."

|> Q4. Do the benefits in Q3 make up for the costs in Q1 and Q2?

Since there are no costs in Q1 and Q2, obviously.  Of course, there is
a cost for compiler writers, and a cost for the standards committee.

|> If adopted, operator dot would probably be analogous to operator arrow.
|> It would have to return a class or reference to a class on which either
|> operator dot was defined, or which had a member corresponding to the name
|> on the right side of the original dot.  Given this, there would be no
|> way to use the ordinary dot on a class with operator dot, just as there
|> is no way to use the ordinary arrow on a class with an operator arrow.

I agree.  The wording should be the same as what appears in 13.4.6 of the ARM,
except that where "pointer" appears "reference" should be substituted.

|> In particular, you would not define both operator dot and operator arrow
|> for the same class.  The result would be unmanageable.

I agree that in practice, an object will either behave as a smart reference
or a smart pointer and not both, but I don't think the compiler should
enforce this restriction.  It's still possible for an object to refer
to its own members within member functions without mentioning either the
. or -> operator.  When teaching someone the language, though, I'd discourage,
STRONGLY, redefining both for the same object.

Smart references will make it easier to write garbage collectors (though
the C-compatible array semantics can leave holes in the scheme).


--
Joe Buck
jbuck@galileo.berkeley.edu	 {uunet,ucbvax}!galileo.berkeley.edu!jbuck