🚀 go-pugleaf

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