🚀 go-pugleaf

Dan;


>>  Is operator.() banned from the standards discussion?

No, but the time for public contributions to the standards discussion 
ended over 6 months ago.


>> Ideally, operator.() should allow you to have all the things
>> inheritance allows you to have, except for storage. I.e. a class
>> with operator.() should behave just as its "base class", but be
>> allowed to override suitable functions.
>> Why isn't this possible? What's the catch?

New facilities are not added to the C++ language when their effect can be 
attained by a little programming using existing facilities.

From your description, it seems to me that an your operator.() object 
method would return a reference to another object, and the named member 
function would be called in that object. For example, here is class 
Handle acting as a proxy for a class Bitmap;


   Handle h ;          // class Handle overloads operator.()
   h.display() ;       // h returns a reference to a Bitmap object
                       // whose display() is then called


Operator.() was not overloaded because you can achieve exactly this same 
effect without it, if the clas Handle has a set of member functions 
matching those in Bitmap, The Handle member functions can simply make 
inline calls to the Bitmap member functions; they can also override to 
change behaviour where necessary:


class Handle {
   Bitmap & ref ;
public:
   bool display()
   {
        return  ref.display() ;
   }
} ;


Various implementations of this kind of scheme are described in the 
literature, for example Coplein, My favourite implementation is where the 
handle class, and the genuine class, both inherit their interface from 
the same abstract base class.


                                       David Byrden



           || C++ training for professional programmers ||
           ||   My opinions ARE those of my employer.   ||



[ 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. ]

In article 1663@et.se, Dan Holmsand <dan@et.se> writes:

>Is operator.() banned from the standards discussion?

No, it is not banned, but it has already had more chances and more
discussion than any other proposal for language extension, bar none.
(One argument goes that it isn't an extension since it merely removes
a restriction, but let's not quibble.)

Operator.() was the subject of heated debate in this forum for about three
years. It was the subject of extensive debate and several proposals in the C++
Committee over a period of about three years. After a proposal was voted down
by an overwhelming majority of the committee, the major proponent
of operator.() persuaded people that it had not received fair treatement.
Yet another proposal was submitted, debated, and voted down by an
overwhelming majority. (No other firmly rejected proposal has been accorded
so many chances.)

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".
---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ 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. ]

In article <3102AD11.1663@et.se> Dan Holmsand <dan@et.se> writes:

> Is operator.() banned from the standards discussion?

Yes.
-- 
				--Andrew Koenig
				  ark@research.att.com
---
[ 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. ]

In article <3102AD11.1663@et.se>,
Dan Holmsand <dan@et.se> asks

dan> Is operator.() banned from the standards discussion?

and in article <DLost8.H9B@research.att.com>,
ark@research.att.com (Andrew Koenig) replies

ark> Yes.

but in article <4e0nc3$4dp@engnews1.Eng.Sun.COM>,
clamage@Eng.Sun.COM (Steve Clamage) writes:

clamage> No, it is not banned, [...]

So who's right, the editor or the chairman? ;-)

--
Fergus Henderson             	WWW: http://www.cs.mu.oz.au/~fjh
fjh@cs.mu.oz.au              	PGP: finger fjh@128.250.37.3

[ 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. ]

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. ]

Dan Holmsand <dan@et.se> writes:
>Is operator.() banned from the standards discussion?

Yes, I suppose it is, but since you brought it up I'll discuss it anyway.

A formal proposal to add it (from Jim Adcock of Microsoft) was voted down
some time ago.  The Adcock proposal was quite simple: "operator dot" would
work just like operator-> except that where operator-> returns a pointer,
operator. would return a reference.  The language in the standard would
be almost identical except for simple substitutions of words.  The
advantage of this was that it would be absolutely clear what the
modification would mean and what the language should be.

Some committee members objected that it's against the philosophy of C++ to
change the meaning of a builtin operator ("."  operating on class object)
-- though we already have operator& whose builtin meaning can be changed.

Others favored a more complex and non-orthogonal version, or, worse, first
said the proposal should be more complex and non-orthogonal and then
objected to the complexity and non-orthogonality in this modified version.

Others objected that if both operator. and operator-> were overloaded the
class would be just about impossible to implement, ignoring the fact that
no one (who understands that providing operator-> gives your object
pointer semantics and operator. gives your object reference semantics, and
you'd want to choose only one) would do this.

Others (those I respect the most) just said they didn't want extensions
without an extremely strong reason, didn't see a strong enough reason for
operator dot, but just wanted to get C++ standardized.  This does make
sense (it would make more sense if so many *other* extensions had not been
accepted).

I think that this rejection was a mistake, as the lack of operator dot
complicates the implementation of delegation (e.g. in classes that use a
reference-counted representation object where the representation object
has virtual functions).  I subscribe to the "write things once"
philosophy, and hate long lists like

class Foo {
private:
	FooRep * rep;
public:
	...
	void foo() { rep->foo();}
	int bar(int arg) { return rep->foo(arg);}
	... and about a dozen more
};

With operator. this would become

class Foo {
private:
	FooRep * rep;
public:
	FooRep& operator.() { return *rep;}
};

and now you can call foo(), bar(int) etc on objects of class Foo.  It
is possible, but confusing, to use operator-> here, but then the Foo
object looks like a pointer, and this isn't the type of programming
interface that is desired in this situation.

But it's too late for major changes at this stage; what's more important
is to complete the standard.  We lost the vote, and it's time to move on.

In the meantime, anyone who wants to experiment with the idea can probably
track down g++ patches that implement operator dot along the lines of
the Adcock proposal -- I've seen mention of these on the net, but I
don't know where they are.

-- 
-- 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. ]

I agree with Joe Buck - this issue is at this stage dead and buried, at
least for this round of standardization.  But I can't let comments like
these pass unchallenged ;-)

David Byrden <100101.2547@compuserve.com> writes:

>New facilities are not added to the C++ language when their effect can be 
>attained by a little programming using existing facilities.
>
>From your description, it seems to me that an your operator.() object 
>method would return a reference to another object, and the named member 
>function would be called in that object. For example, here is class 
>Handle acting as a proxy for a class Bitmap;
[...]
>Operator.() was not overloaded because you can achieve exactly this same 
>effect without it,

Perhaps you can in this particular case...

>if the clas Handle has a set of member functions matching those in Bitmap,

... but only with a lot of tedious programming.  Furthermore, all those
forwarding functions are a maintenance problem; every time you add
a new function to Bitmap, you need to remember to add one to Handle.

Now, please tell me how to write a template smart reference class without
using operator.()?  Can I attain that effect "with a little programming
using existing facilities"?  I think not.

--
Fergus Henderson             	WWW: http://www.cs.mu.oz.au/~fjh
fjh@cs.mu.oz.au              	PGP: finger fjh@128.250.37.3
---
[ 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. ]

jbuck@Synopsys.COM (Joe Buck) writes:

>In the meantime, anyone who wants to experiment with the idea can probably
>track down g++ patches that implement operator dot along the lines of
>the Adcock proposal -- I've seen mention of these on the net, but I
>don't know where they are.

I originally made the patches by modifying gcc-2.3.3.
The patches, updated to apply to gcc-2.4.0, are now available from

	http://www.cs.mu.oz.au/~fjh/comp.std.c++/gcc-2.4.0-opdot.patch

I think the 2.4.0 patches applied cleanly to 2.6.3, but I haven't tried
them with 2.7.2.  The patches include additions to the gcc documentation
which describe the exact semantics implemented.

--
Fergus Henderson             	WWW: http://www.cs.mu.oz.au/~fjh
fjh@cs.mu.oz.au              	PGP: finger fjh@128.250.37.3

[ 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. ]

Joe Buck (jbuck@Synopsys.COM) wrote:
: Dan Holmsand <dan@et.se> writes:
: >Is operator.() banned from the standards discussion?

: Yes, I suppose it is, but since you brought it up I'll discuss it anyway.

[text elided]

: I think that this rejection was a mistake, as the lack of operator dot
: complicates the implementation of delegation (e.g. in classes that use a
: reference-counted representation object where the representation object
: has virtual functions).  I subscribe to the "write things once"
: philosophy, and hate long lists like

I'm afraid there is something I don't understand about this approach.  For
a nontrivial class, one in which you have a delegate pointer and other
members, how would you propose the compiler discriminate between
overloaded (delegative) member selection and the selection of actual
members of the class?  This would become an issue as soon as a member
function tries to access member data or a user of the class attempts to
form a call to a member function.

Only one scheme is immediately apparent to me; use a two-step member
selection candidate approach.  Whether actual or delegative members are
given precedence in such a scheme, the approach would be incongruent and
perhaps contradictory with how the language solves other problems.

The -> operator has the advantage that it signals the delegation property
of the member selection when it's performed.  It's easy enough for the
programmer to ignore that aspect when it's adventageous for him to do so. 
It is also easy enough to identify that aspect when it is an issue.  "I
know this identifier is a reference or an object but here is this pointer
member selection operator being used so I know delegation is being used."
---
[ 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. ]

In article <4easfd$puc@news2.delphi.com> jodle@bix.com (jodle) writes:

> I'm afraid there is something I don't understand about this approach.  For
> a nontrivial class, one in which you have a delegate pointer and other
> members, how would you propose the compiler discriminate between
> overloaded (delegative) member selection and the selection of actual
> members of the class?  This would become an issue as soon as a member
> function tries to access member data or a user of the class attempts to
> form a call to a member function.

There's a long discussion of operator. in D&E, and some of it
addresses precisely this point.  If you're interested in operator.,
you may find that discussion useful: it may not change your opinion of
whether or not operator. is a good idea, but it'll probably give you a
clearer idea of some of the issues.

I've never had a strong opinion about operator. one way or the other
(I have slightly different operator fetishes), but I do think it's
quite clear that operator. will not make it into the C++ standard.
Still, it's interesting from a theoretical and historical perspective.

-- 
Matt Austern
SGI: MTI Compilers Group
austern@isolde.mti.sgi.com
---
[ 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. ]

jodle@bix.com (jodle) writes:

>I'm afraid there is something I don't understand about this approach.  For
>a nontrivial class, one in which you have a delegate pointer and other
>members, how would you propose the compiler discriminate between
>overloaded (delegative) member selection and the selection of actual
>members of the class?  This would become an issue as soon as a member
>function tries to access member data or a user of the class attempts to
>form a call to a member function.

Jim Adcock proposed that if `.' was overloaded, then `.' always meant
the overloaded version, not the built-in version.  That's what I
implemented.  I think these simple semantics are quite sufficient to
achieve the desired functionality.  Here's the documentation included
in the gcc patch I previously posted, which explains how the problem
you refer to can be solved.

-----------------------------------------------------------------------------

Overloading Operator Dot for Smart References
=============================================

   Just as standard C++ allows you to overload `operator->()' to create
"Smart Pointer" classes, GNU C++ allows you to overload `operator.()'
to create "Smart Reference" classes.

   Overloading `operator->()' or `operator.()' is different to
overloading the other binary operators, because the right hand operand
is a field name, not an expression.  The overloaded operator function
takes only a single argument, the left hand operand, and returns a
pointer (for `operator->()') or a reference (for `operator.()') which
the compiler then uses in combination with the field name to produce
the final result.  Essentially, overloading operator dot is exactly the
same as overloading operator arrow except that where operator arrow
uses pointers, operator dot uses references.

   For any class X which overloads the dot operator, the compiler
replaces all expressions of the form `x.m' with `(x.operator.()).m'.
If the result of `X::operator.()' is a class type which also overloads
dot, then the result is recursively subject to the same expansion.
(Note that the first dot in `x.operator.()' is meant to represent the
builtin operator dot and is not subject to recursive expansion, for
otherwise we would get an infinite regress.)

   The overloaded `operator.()' will be invoked only when there is an
actual dot operator present in the source code. If a member function is
invoked without using a dot operator, then `operator.()' will *not* be
invoked.  Conversely, a dot expression *always* invokes the appropriate
`operator.()' if that operator has been overloaded.  This means that if
class `X' contains a member function `f()' but `X' overloads operator
dot to return `Y&', then the following code

     X x;
     x.f();

calls `Y::f()', not `X::f()'.

   Most of the time, this behaviour is exactly what you want.
Sometimes however, you do want to access member functions of your smart
reference class.  For example, suppose you have defined a class
`DiskReference' which acts as a reference to data which is stored on
disk.  The class caches the disk value in memory, and the cache is
written back to the disk by the destructor.  Your class users may
occaisionally want to explicitly flush the cache, so the `DiskReference'
class should provide a class method `flush()' to do that.

   If you do want to access members of `DiskReference', then you need
to do so without using the dot operator.  If the member(s) you want to
access are overloaded operators, then you can just use the operator
notation.  For other members, if you haven't overloaded `operator&()',
you can use `(&x)->m'.  But it's often nice to overload operator& to
return a smart pointer.  In this case, the best thing to do is to put
most of the details of DiskReference in a base class, say
DiskReferenceControl, which doesn't overload operator dot, and then
invoke the members using a reference to DiskReferenceControl.  For
example:

     foo(DiskReference& x) {
         DiskReferenceControl& x_control(x);
         x_control.flush();	// flushes x to disk
     }

You could also simplify the calling of DiskReferenceControl member
functions, using a helper function a function `control()' like this:

     inline DiskReferenceControl& control(DiskReference& x) { return x; }
     
     foo(DiskReference& x) {
         control(x).flush();
     }

-----------------------------------------------------------------------------

Another alternative not mentioned in the documentation is do just
put all the relevant functions in the smart pointer, not the
smart reference; if you need to invoke one of them on a smart
reference, use the overloaded & operator to convert from a smart
reference to a smart pointer: `(&x).foo();'.

>The -> operator has the advantage that it signals the delegation property
>of the member selection when it's performed.  It's easy enough for the
>programmer to ignore that aspect when it's adventageous for him to do so. 
>It is also easy enough to identify that aspect when it is an issue.  "I
>know this identifier is a reference or an object but here is this pointer
>member selection operator being used so I know delegation is being used."

Overloadable operator -> is great, but it only gives you smart pointers,
not smart references.  I think the approach outlined above has similar
advantages of making it clear when delegated members are being selected
and when the non-delegated members are being selected.  But the point of
overloading . rather than -> it gives you smart references, not smart pointers.


--
Fergus Henderson             	WWW: http://www.cs.mu.oz.au/~fjh
fjh@cs.mu.oz.au              	PGP: finger fjh@128.250.37.3
---
[ 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. ]

>>>>> Joe Buck <jbuck@Synopsys.COM> writes:

> 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".

I think a more natural way to achieve the delegation semantics proposed by
Stroustrup would be to extend 'using' along these lines:

struct A {
  void f  ();
};

struct ARef {
  A* a;
  using *a;
};

main ()
{
  ARef ar = { new A };
  ar.f (); // (*(ar.a)).f();
}

Of course, that's not likely to happen either.

Jason

[ 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. ]

First of all, I suppose there is no difference bewten A + B, A.operator+ (B)
and A.plus (B) when operator+ is defined as plus.

Suppose first you overload operator+, then you overload operator. in MyClass:

class MyClass {
private:
   AnnotherClass* theOtherClass;
public:
   AnnotherClass operator. ();
   MyClass       operator+ (int);
   void          Something_only_defined_in_MyClass ();
};

MyClass A;

A + 2; is equivalent with A.operator (2) and (A.operator.).operator (2)

You can't even write (&A)->Something_only_defined_in_MyClass () in order to
access Something_only_defined_in_MyClass (which is only defined for MyClass):
(&A)->a_member is equivalent with ((A.operator.).operator&)->a_member.

How can yu access Something_only_defined_in_MyClass ?

If operator. return theOtherClass, why don't you just write:
AnnotherClass*	theOtherClass;

theOtherClass + 2;

Note that A.m _is equivalent_ (provided that operator. is not overloaded in 
AnnotherClass) with (&A)->m.

Valentin Bonnard
bonnardv@pratique.fr
---
[ 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. ]

Valentin Bonnard <bonnardv@pratique.fr> writes:

>First of all, I suppose there is no difference bewten A + B, A.operator+ (B)
>and A.plus (B) when operator+ is defined as plus.

No, not in the semantics which Jim Adcock proposed and which I implemented.
The rule is very simple: you invoke the `operator . ()' function, if any,
if and only if the source code contains a `.'.  So `A.operator+(B)' and
`A.plus(B)' will invoke `operator . ()', but `A + B' will not.

>Suppose first you overload operator+, then you overload operator. in MyClass:
[...]
>MyClass A;
>
>A + 2; is equivalent with A.operator (2) and (A.operator.).operator (2)

Nope, according to Jim Adcock's proposal, `A + 2' would not invoke the
user-defined `operator . ()' function.  See above.

>You can't even write (&A)->Something_only_defined_in_MyClass () in order to
>access Something_only_defined_in_MyClass (which is only defined for MyClass):

Nope, according to Jim Adcock's proposal, for your example you are free to
do so.

>Note that A.m _is equivalent_ (provided that operator. is not overloaded in 
>AnnotherClass) with (&A)->m.

Nope, according to Jim Adcock's proposal that is not necessarily true either.
This is just like `x++' not necessarily being equivalent to `x = x + 1'
if you have overloaded `operator ++'.

With Jim Adcock's proposal, if you overload `operator .', you can make
the equivalence hold, by also overloading `operator &' to return a
smart pointer class.  Without his proposal, if you overload `operator &',
in the general case there is no way to make the equivalence hold.

--
Fergus Henderson             	WWW: http://www.cs.mu.oz.au/~fjh
fjh@cs.mu.oz.au              	PGP: finger fjh@128.250.37.3
---
[ 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. ]

In article <4eqr6b$778@s3.iway.fr> Valentin Bonnard
<bonnardv@pratique.fr> writes:

|> First of all, I suppose there is no difference bewten A + B,
|> A.operator+ (B) and A.plus (B) when operator+ is defined as plus.

|> Suppose first you overload operator+, then you overload operator. in
|> MyClass:

|> class MyClass {
|> private:
|>    AnnotherClass* theOtherClass;
|> public:
|>    AnnotherClass operator. ();
|>    MyClass       operator+ (int);
|>    void          Something_only_defined_in_MyClass ();
|> };

|> MyClass A;

|> A + 2; is equivalent with A.operator (2) and (A.operator.).operator (2)

No, at least not as I understand the proposal.  A + 2 causes
MyClass::operator+ to be called, with &A as this, and 2 as the
argument.  The operator.() function would only be called when a `.'
appears in the equation.

|> You can't even write (&A)->Something_only_defined_in_MyClass () in
|> order to access Something_only_defined_in_MyClass (which is only
|> defined for MyClass): (&A)->a_member is equivalent with
|> ((A.operator.).operator&)->a_member.

No, the type of `&A' is MyClass*.  There is no operator.() defined for
this type, nor can there ever be.  There is an operator-> defined, the
built in one.

If I write (&A)->, the compiler uses (the built-in) operator&, then
operator-> on the results.  What makes you think it could do anything
else?

|> How can yu access Something_only_defined_in_MyClass ?

|> If operator. return theOtherClass, why don't you just write:
|> AnnotherClass*	theOtherClass;

Because typically, `AnotherClass' is a proxy class (a smart
reference), the user doesn't even know about it, and cannot name it if
he is (since it will be declared private in the container class).

--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, itudes et rialisations en logiciel orienti objet --
                -- A la recherche d'une activiti dans une region francophone
---
[ 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. ]

Joe Buck wrote:
> 
> Dan Holmsand <dan@et.se> writes:
> >Is operator.() banned from the standards discussion?
> 
> Yes, I suppose it is, but since you brought it up I'll discuss it anyway.
> 
> A formal proposal to add it (from Jim Adcock of Microsoft) was voted down
> some time ago.  []
> 
> Some committee members objected that it's against the philosophy of C++ to
> change the meaning of a builtin operator.[]
> 
> Others favored a more complex and non-orthogonal version, or, worse, first
> said the proposal should be more complex and non-orthogonal and then
> objected to the complexity and non-orthogonality in this modified version.
> 
> Others objected that if both operator. and operator-> were overloaded the
> class would be just about impossible to implement, []
> 
> Others (those I respect the most) just said they didn't want extensions
> without an extremely strong reason, didn't see a strong enough reason for
> operator dot, but just wanted to get C++ standardized.  []

	For the record the _principal_ argument against 
operator.() which killed the proposal was simply that it
failed to actually provide smart references: an explicit
dot was required.

	For pointers, operator-> is OK, because
when no -> is used, you want a pointer and get
a smart pointer, and when you want an lvalue,
you have to use and explicit -> or * anyhow. 

	But for references, this is not so: 
"f(lvalue &)" requires an lvalue argument.
Operator.() (as proposed by Jim Adcock) doesn't
convert the smart reference object to a refernece
to its delegee in this context.

	As I understand it this fact was considered to
cast enough doubt on the utility of Jim's proposal
to reject it, particularly considering the potential
confusion created, and the general lack of consensus
on the issue.


-- 
John Max Skaller               voice: 61-2-566-2189
81 Glebe Point Rd              fax:   61-2-660-0850
GLEBE NSW 2037                 web: http://www.maxtal.com.au/~skaller/
AUSTRALIA                      email: skaller@maxtal.com.au
---
[ 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. ]

Jason Merrill wrote:
> 
> >>>>> Joe Buck <jbuck@Synopsys.COM> writes:
> 
> > Stroustrup proposes that operator. only forward to the resulting class
> > for a.m if the object itself doesn't have a member m. 

	He did?

	Stroustrup actually proposed -- AND implemented and tested:

	struct X : *Y { .. };

which looked good to me. He said that programmers found it
hard to use, however, and dropped it.

> I think a more natural way to achieve the delegation semantics proposed by
> Stroustrup would be to extend 'using' along these lines:
> 
> struct A {
>   void f  ();
> };
> 
> struct ARef {
>   A* a;
>   using *a;
> };

	I believe _I_ first proposed that. Again,
it looks good on the surface but until precise details
are given it isn't easy to see exactly what the
consequences will be. As with deriving from 
an expression (Bjarne's idea) it may just turn out
to be to hard to use -- even if it works.
-- 
John Max Skaller               voice: 61-2-566-2189
81 Glebe Point Rd              fax:   61-2-660-0850
GLEBE NSW 2037                 web: http://www.maxtal.com.au/~skaller/
AUSTRALIA                      email: skaller@maxtal.com.au
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy is
  in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]