🚀 go-pugleaf

clamage@Eng.Sun.COM writes:
>It's hard for me to imagine that anyone could come up with new arguments
>in favor of operator.() that also answer the objections to it. If you think
>you can do so, go ahead, but do yourself and everyone else a favor and
>acquaint yourself with the discussion that has already occurred. Note
>especially the arguments in the ARM and D&E against "operator dot".

Since I want a language standard soon, I'll live without operator dot.
But I will object to attempts to rewrite history.

Please note that in D&E Stroustrup does not argue against overloaded
operator dot, but rather against specific proposals.  Unfortunately,
Stroustrup's arguments against specific overloaded operator dot proposals
are rather embarrassing for him, not up to his usual standard of skillful
writing.  But if you wish, I will answer them.

In D&E, section 11.5.2, he objects that obj.m already has a meaning,
and that overloading operator. would thus make the language mutable,
but he admits that the rule is broken for operator= and operator&.

The second objection, that overloading both operator. and operator->
would cause problems, is also easily dismissed.  The answer is simple:
"don't do that".  One overloads operator. to make a class that has
reference semantics.  One overloads operator-> to make a class that
has pointer semantics.  It would be bad design to make an object that
works like both a pointer and a reference, so the fact that such classes
are difficult to write because you can't get to their members is not an
issue.

Stroustrup then comes to the Adcock proposal.  He points out its benefits
in implementing delegation (a "handle" class or a "proxy" class).  He
then objects that overloading operator. does not do the complete job
(he says "doesn't have the right effect") because there are cases
where the dot is not mentioned (when overloaded operators are used)
so that there is still the need to write forwarding functions for
them.  He states "this is clearly tedious".  But the tedium is
substantially reduced with respect to what it is now (no forwarding
functions for normal member functions, only overloaded operators).
Since many classes don't overload *any* operators, this tedium reduces
to zero.

Note that the example he chooses stacks the deck against the Adcock
proposal, in that the proxy class has one member function and two
overloaded operators, meaning that overloaded operator dot saves only
one forwarding function.  But I have several examples in the project
I am currently working on where there are eight to twelve functions
to be forwarded and no overloaded operators.  I need to write inline
functions for every last one of them, and all changes have to be
done in two places.

Stroustrup then describes a *new* proposal in which operator. has the
magic behavior of also forwarding overloaded operators.  There was
evidently disagreement in the committee over which is better (I think the
Adcock proposal is cleaner myself, though I could live with this one).
Not mentioned here, but mentioned in some comp.std.c++ discussions,
is that people objected to that one because of the "surprise factor"
(I wrote no dot, why is operator. being called?).

He next objects that overloading operator. breaks the equivalence of
a.m and (&a)->m.  Sorry, Dr. Stroustrup, there is no such equivalence,
thanks to overloaded operator & .  The symmetry was broken by the
creation of "smart pointers".  Symmetry can be restored by dropping
operator& and operator->, or by adding operator dot.

He then points out that you could restore this symmetry when overloading
operator. by generating automatic overloads operator& and operator-> to
match operator. and immediately points out that this would cause problems.
But this is a straw man.  Never before in C++ did overloading one operator
change others.  Overloading += doesn't create a matching overload for + to
force a consistent meaning for addition.  Why raise hoops for
extensions that the core language cannot meet?  Why make the language
inconsistent in this way?

"We are thus left in a quandry: we can either maintain the a.m and
(&a)->m equivalence or have access to members of the smart reference,
but not both".  False.  There is already operator&.  There is no
guaranteed equivalent in the language of a.m and (&a)->m today,
with or without any extensions.  We can exploit the broken symmetry and
allow access to members of the smart reference with (&a)->m.

Stroustrup proposes that operator. only forward to the resulting class
for a.m if the object itself doesn't have a member m.  I dislike that
approach; it is unnecessary since (&a)->m accesses it, and since
the class is going to present itself as a disguised reference object
in any case, only private code is going to mess around with the object's
own members.  In member functions, one would merely write "m".


-- 
-- Joe Buck 	<jbuck@synopsys.com>	(not speaking for Synopsys, Inc)

Work for something because it is good,
not just because it stands a chance to succeed.	   -- Vaclav Havel

[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]