sjmccaug@prairienet.org (Scott J. McCaughrin) writes:

>In a previous article, david.tribble@central.beasys.com (David R Tribble) says:

>>S. Cao wrote:
>>> Could someone tell me why when overloading the assignment (=)
>>> operator,
>>> the operator overloading function has to be a member function?

>>This is because the expression 'a = b' is, by definition, exactly
>>the same as 'a.operator=(b)' if the type of 'a' is anything other
>>than a built-in type (such as 'int').

> What if a and b are both structs of the same type?

It makes no difference.
It will still call a.operator=(b) , it just may be the case that the
  operator=() member will be compiler created. (ie bitwise)
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Timothy Philip Vernum wrote in message ...
>
>sjmccaug@prairienet.org (Scott J. McCaughrin) writes:
>>
>> What if a and b are both structs of the same type?
>> [in the expression a = b]
>
>It makes no difference.
>It will still call a.operator=(b) , it just may be the case that the
>  operator=() member will be compiler created. (ie bitwise)

Not to nitpick, I just want to make sure someone doesn't get the wrong
impression.  A compiler implicitly defined assignment operator
performs a memberwise assignment.  This is not necessarily a bitwise
assignment, it could end up calling a member operator= function of a
subobject.  It also coppies arrays by doing an elementwise assignment.
All the assignments are done in the order in which the subobjects are
declared in the class definition.

-Chris
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <6dlqfj$6nq$1@vixen.cso.uiuc.edu>,
  sjmccaug@prairienet.org (Scott J. McCaughrin) wrote:
>
> In a previous article, david.tribble@central.beasys.com (David R Tribble)
says:
>
> >S. Cao wrote:
> >> Could someone tell me why when overloading the assignment (=)
> >> operator,
> >> the operator overloading function has to be a member function? (which
> >> is also required for (), [] and ->).  I have checked several c++ books
> >> I have, all of them only stated the rule but no further explanations.
> >> Thanks in advance.
> >
> >This is because the expression 'a = b' is, by definition, exactly
> >the same as 'a.operator=(b)' if the type of 'a' is anything other
> >than a built-in type (such as 'int').
>
>  What if a and b are both structs of the same type?

If the user hasn't declared one in the struct, the compiler generates
a public operator=.

On the other hand, the original statement is false for pointers,
and even more false for C style arrrays (not to mention references).

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
        +49 (0)69 66 45 33 10    mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung


-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In a previous article, david.tribble@central.beasys.com (David R Tribble) says:

>S. Cao wrote:
>> Could someone tell me why when overloading the assignment (=)
>> operator,
>> the operator overloading function has to be a member function? (which
>> is also required for (), [] and ->).  I have checked several c++ books
>> I have, all of them only stated the rule but no further explanations.
>> Thanks in advance.
>
>This is because the expression 'a = b' is, by definition, exactly
>the same as 'a.operator=(b)' if the type of 'a' is anything other
>than a built-in type (such as 'int').

 What if a and b are both structs of the same type?
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Valentin Bonnard wrote in message <34EB8EDB.54B9@pratique.fr>...
>I don't understand why an operator which has no predefined
>meaning can't be a non-member (that is, any operator except
>op=, unary op&, and op,).


They probably could.  Mr. Stroustrup says that restricting operators [], (),
and -> to member functions "...seemed a harmless restriction that eliminated
the possibility of some obscure errors..." of the sort you mentioned.
However, he goes on to say "...it is probably a case of unnecessary
nannyism"(See THE DESIGN AND EVOLUTION OF C++, section 3.6.2).

So you are right.  C++ could allow these to be nonmember functions.  But
under the principal of "if it isn't broken, don't fix it", why should we now
change C++ to allow it?  What practical advantage is there in allowing []
and -> to be nonmember functions?  Do the advantages outweigh the risks?




[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble wrote:
>
> S. Cao wrote:
> > Could someone tell me why when overloading the assignment (=)
> > operator,
> > the operator overloading function has to be a member function?
> > (which is also required for (), [] and ->).  I have checked
> > several c++ books I have, all of them only stated the rule
> > but no further explanations.
>
> This is because the expression 'a = b' is, by definition, exactly
> the same as 'a.operator=(b)' if the type of 'a' is anything other
> than a built-in type (such as 'int').  Basically, C++ enforces
> the object-oriented concept that all operations on a class type
> are defined by the class, i.e., you can't do anything to a class
> object unless it's an operation defined by the class.  This means
> that all operations must be member functions of the class.  Since
> (almost) all of the operators (=, +, -, *, /, [], ->, (), etc.) act
> this way, by definition, you can see that they must be class member
> functions.

Is this some new rule? I always thought that operators
+, -, *, / can be non-members. Moreover, as far as I can
remember, there are some style guides that recommend that
they are defined as non-member, e.g. for symmetry of
operations.

fres


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Piet Van Vlierberghe wrote:
>
> Mungo Henning <mungoh@itacs.strath.ac.uk> wrote in article
> <34E848A7.8185CA73@itacs.strath.ac.uk>...
> > S. Cao wrote:
> > >
> > > Could someone tell me why when overloading the assignment (=) operator,
> > > the operator overloading function has to be a member function? (which
> > > is also required for (), [] and ->).
> >
> > Consider (off the top of my head: not tested!):
> >

[... example with assignment declared too late ...]

> >
> > The function bar() will use the built-in assignment operator, whereas
> > bar2() will use the user's operator= instead. Position of code within a
> > source file has an effect on whether the default assignment operator or
> > the user's assignment operator is used.  If the language insists that
> > an overloaded assignment operator must be a member, you don't run into
> > this positional problem.
>
> But this cannot be the only reason, I guess, since your reasoning holds for
> _all_ operators, not just assignment. The rule at hand, however, cites only
> the assignment operator. Consider the following example. The function f()
> is identical to the function g(), but behaves differently, solely because
> of its position in the
> compilation unit:
>

[... example with operator<< for derived type declared too late ...]

I think it's a different problem here, as the operator declarations are
different (they belong to a different type). In the assignment case,
the assignment operator is generated *with the same signature* or
with a signature which causes ambiguities in *every* case, or even
worse, an assignment with const rhs argument may be generated although
an assignment with non-const rhs argument was given by the programmer,
thus affecting even code coming *after* the user declaration.
You don't want the legality of some code fragment to depend on the
fact if some completely unrelated function comes before or after
declaration of operator=, do you?

However, I don't understand the reason why [], () and -> must be
members - none of them are generated implicitly, and except for
operator-> there's not even a special rule concering with them
(except the rule that they must be members, of course).

It certainly prohibits things like this:

double& operator[](int i, vector<double>& v) { return v[i]; }

but that cannot be the reason (Other operators can be misused
this way as well).


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Piet Van Vlierberghe wrote in message
<01bd3b75$692d97d0$7f0acac1@amundsen>...
>But this cannot be the only reason, I guess, since your reasoning holds for
>_all_ operators, not just assignment.

I have found two explanations for this.  The first is THE DESIGN AND
EVOLUTION OF C++, Section 3.6.2.  There Mr. Stroustrup says that it was
indeed to avoid ordering problems, especially between files.  What made
assignment different from other operators was that there is a default
definition for the assignment operator, whereas other operators such as +=
were not defined by default for classes.

A second reason is given in THE C++ PROGRAMMING LANGUAGE, Third Edition,
Section 11.2.2.  There Mr. Stroustrup says that requiring assignment to be a
nonstatic member function ensures that its first operand will be an lvalue.




[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Matt Seitz wrote:

[ Why op= is a member function ]

> A second reason is given in THE C++ PROGRAMMING LANGUAGE, Third Edition,
> Section 11.2.2.  There Mr. Stroustrup says that requiring assignment to be a
> nonstatic member function ensures that its first operand will be an lvalue.

This is completly wrong. It's even the contrary: requiring
operator= to be a non-member would garanty lvalue-ness.

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://www.pratique.fr/~bonnardv/


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Steve Clamage wrote:

> Now consider assignment, [], and ->. If conversion occured on
> the left operand, you could create a temp object, operate on the
> temp, discard the temp, and the real operand would remain unaffected.
> It is very unlikely that you would want that behavior for these
> functions. Type conversion never occurs on the object ("this")
> parameter to a member function, so the problem does not arise.

I'm sorry, I don't by this argument. Why [] and -> ? Probably
because they refer to sub-objects pointed to by the object on
which they are called. And they return a lvalue (or a pointer,
it's the same thing actually ;-)  ). So a temporary seems
unappropriate. But this would apply to unary * too, wouldn't
it ?

Also what about ->* ?

I don't understand why an operator which has no predefined
meaning can't be a non-member (that is, any operator except
op=, unary op&, and op,).

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://www.pratique.fr/~bonnardv/


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Could someone tell me why when overloading the assignment (=) operator,
the operator overloading function has to be a member function? (which
is also required for (), [] and ->).  I have checked several c++ books
I have, all of them only stated the rule but no further explanations.
Thanks in advance.

Susan
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

S. Cao wrote:
>
> Could someone tell me why when overloading the assignment (=) operator,
> the operator overloading function has to be a member function? (which
> is also required for (), [] and ->).

Consider (off the top of my head: not tested!):

class foo {
 // all the usual sundries omitted for brevity
};

foo a,b;

void bar()
{
 a = b;
}

void operator=(foo& x, foo& y)
{
}

void bar2()
{
 a = b;
}

The function bar() will use the built-in assignment operator, whereas
bar2() will
use the user's operator= instead. Position of code within a source file
has an
effect on whether the default assignment operator or the user's
assignment operator
is used.
If the language insists that an overloaded assignment operator must be a
member,
you don't run into this positional problem.

Hope I've re-told the reasoning adequately.

Mungo Henning
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <6c2sd4$gvb@freenet-news.carleton.ca>,
dq250@FreeNet.Carleton.CA says...
> Could someone tell me why when overloading the assignment (=) operator,
> the operator overloading function has to be a member function? (which
> is also required for (), [] and ->).  I have checked several c++ books
> I have, all of them only stated the rule but no further explanations.

Overloading an operator with a global function is done to allow the
left hand operand to be something other than a class object.  For
example, assume you've got a string class that can take two strings
and create a new string of the two concatenated together.  It's
perfectly reasonable for either the left or right hand operand (or
both) to be either an existing String object OR a string literal.  As
such, if you were going to use operator+ to support this, you'd want
to do it as a global function so either or both operands could be a
string literal.

However, with the assignment operator things are a bit different: it
does NOT make sense to support assignment to a string literal.  e.g.
if I have:

MyString X = "this" + "That";

this should be legal.  However, with assignments:

"This" = X; // should be illegal, but
X = "This";  // should be legal.

By requiring the assignment operator to be a member function, this is
enforced.  The pieces of code above would be interpreted as:

"This".operator=(X); // "This" has no member functions
X.operator=("this"); // X can have a member named `operator='

The same is more or less true with the other operators mentioned; they
only make sense when invoked on an actual object.

--
    Later,
    Jerry.

The Universe is a figment of its own imagination.



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

dq250@FreeNet.Carleton.CA (S. Cao) writes:

>Could someone tell me why when overloading the assignment (=) operator,
>the operator overloading function has to be a member function? (which
>is also required for (), [] and ->).  I have checked several c++ books
>I have, all of them only stated the rule but no further explanations.

The operators which do not need to be class members are those which
have no predefined meaning for a class type. For example, if you
write x+y where x or y has a class type, the code is invalid
unless a declaration for an appropriate operator+ is in scope
at the point of the call.

Now suppose for class T you could write
 T& operator=(T&, const T&); // not a member of T
Since assignment is predefined for all class types, the meaning of
 t1 = t2; // both of type T
would depend on whether a declaration for the overloaded assignment
were in scope. That's bad -- a source of very subtle bugs. You could
argue that similar problems exist for all overloaded functions,
but assignment is a fundamental, prefined operation. That's the main
reason for requiring operator= to be a class member function.

The main reason for requiring operator= to be in particular a
*nonstatic* class member function applies to the other special
operators as well.

For a non-member operator function
 T1 operator@(T2, T3); // '@' is any operator
type conversion is allowed on the left (first) operand. Often,
that is exactly the effect we want. Overloading the addition
operator that way allows us to write 1+x as well as x+1 without
having to write two functions, assuming conversions from int to
the type of x.

Now consider assignment, [], and ->. If conversion occured on
the left operand, you could create a temp object, operate on the
temp, discard the temp, and the real operand would remain unaffected.
It is very unlikely that you would want that behavior for these
functions. Type conversion never occurs on the object ("this")
parameter to a member function, so the problem does not arise.

In the case where you really want to create a temp, you can do
so explicitly via a cast. You won't introduce subtle bugs by
the conversion happening invisibly.

--
Steve Clamage, stephen.clamage@sun.com


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

I can't comment directly on the reasons the ANSI or ISO committees made it
so, but
there are are a number of factors to look at to surmise why the assignment
operator
was designed this way. First, there is compatibility with C to consider.
ANSI C
provides a compiler-generated assignment operator for each structure type.
These
perform the equivalent of member-by-member copying.  C++ must do something
compatible with this which means that all C++ classes have an assignment
operator
of some kind or other. Therefore, you the programmer are left with the
option of
overriding that operator.  We can see there would be subtleties and problems
that
arise if the compiler generates one version of assignment within a class and
the programmer tries to provide a different version outside the class. If we
assume
a theoretical compiler that behaves in a manner that is as consistent as is
reasonable
with existing compilers, the compiler would have to disallow overriding the
operator
or do something very special to accomodate it.

To my mind, the semantics of the assignment operator are clearly very
intimately tied to
the internal state of any object it assigns to. This implies direct access
to private data
which further implies class membership.  The alternatives, implicit
friendship, unit-based
polymorphism et cetera, all "feel" like they hide subteties and
difficulties.


S. Cao wrote in message <6c2sd4$gvb@freenet-news.carleton.ca>...
>Could someone tell me why when overloading the assignment (=) operator,
>the operator overloading function has to be a member function? (which
>is also required for (), [] and ->).  I have checked several c++ books
>I have, all of them only stated the rule but no further explanations.
>Thanks in advance.



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Mungo Henning <mungoh@itacs.strath.ac.uk> wrote in article
<34E848A7.8185CA73@itacs.strath.ac.uk>...
> S. Cao wrote:
> >
> > Could someone tell me why when overloading the assignment (=) operator,
> > the operator overloading function has to be a member function? (which
> > is also required for (), [] and ->).
>
> Consider (off the top of my head: not tested!):
>
> class foo {
>  // all the usual sundries omitted for brevity
> };
>
> foo a,b;
>
> void bar()
> {
>  a = b;
> }
>
> void operator=(foo& x, foo& y)
> {
> }
>
> void bar2()
> {
>  a = b;
> }
>
> The function bar() will use the built-in assignment operator, whereas
> bar2() will use the user's operator= instead. Position of code within a
> source file has an effect on whether the default assignment operator or
> the user's assignment operator is used.  If the language insists that
> an overloaded assignment operator must be a member, you don't run into
> this positional problem.

But this cannot be the only reason, I guess, since your reasoning holds for
_all_ operators, not just assignment. The rule at hand, however, cites only
the assignment operator. Consider the following example. The function f()
is identical to the function g(), but behaves differently, solely because
of its position in the
compilation unit:

class Zork {

};

class Foo: public Zork {

};

void operator<< (Zork& a, Zork& b)
{
}

void f ()
{
 Foo a;
 Foo b;

 a << b; // calls operator<< (Zork&, Zork&)
}

void operator<< (Foo& a, Foo& b)
{
}

void g ()
{
 Foo a;
 Foo b;

 a << b; // calls operator<< (Foo&, Foo&)
}
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Piet Van Vlierberghe wrote:
>
> Mungo Henning <mungoh@itacs.strath.ac.uk> wrote in article
> <34E848A7.8185CA73@itacs.strath.ac.uk>...
> > S. Cao wrote:
> > >
> > > Could someone tell me why when overloading the assignment (=) operator,
> > > the operator overloading function has to be a member function? (which
> > > is also required for (), [] and ->).

> > Position of code within a
> > source file has an effect on whether the default assignment operator or
> > the user's assignment operator is used.  If the language insists that
> > an overloaded assignment operator must be a member, you don't run into
> > this positional problem.
>
> But this cannot be the only reason, I guess, since your reasoning holds for
> _all_ operators, not just assignment.

operator= is a special member function, and prevent the
compiler from generating operator= for a class. Same reasonning
for operator&.

But for enums, the only way to define operators is as non-members,
and they disable the implicit ones too:

enum T { a, b };
// bool operator< (T, T) generated at this point
bool operator< (T, T); // we kill the above operator

[Don't tell me the above is wrong; it's _not_.]

But I don't know why () and [] have to be members.

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://www.pratique.fr/~bonnardv/


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

S. Cao wrote:
> Could someone tell me why when overloading the assignment (=)
> operator,
> the operator overloading function has to be a member function? (which
> is also required for (), [] and ->).  I have checked several c++ books
> I have, all of them only stated the rule but no further explanations.
> Thanks in advance.

This is because the expression 'a = b' is, by definition, exactly
the same as 'a.operator=(b)' if the type of 'a' is anything other
than a built-in type (such as 'int').  Basically, C++ enforces
the object-oriented concept that all operations on a class type
are defined by the class, i.e., you can't do anything to a class
object unless it's an operation defined by the class.  This means
that all operations must be member functions of the class.  Since
(almost) all of the operators (=, +, -, *, /, [], ->, (), etc.) act
this way, by definition, you can see that they must be class member
functions.

For convenience, C++ allows the shorthand 'a = b' to mean the same
thing as the longer 'a.operator=(b)'.

Also for convenience, C++ provides some "default" member functions
so you don't have to go to the trouble of coding them for every
class.  The 'operator=()' is one of these default member functions
that the compiler will supply for free if you don't explicitly
declare one for the class.  (The default constructor, copy
constructor, and destructor are others that you get for free.)

For built-in types it's a little bit different.  The built-in types
are not classes, so they don't have member functions or operators.
So given the expression 'a = b', where 'a' is a built-in type, the
compiler attempts to convert 'b' into a compatible type.  For
example, if 'a' is type 'int', then the compiler attempts to find a
conversion operator for 'b' that yields an 'int' type (or something
that can be converted into an 'int').  The obvious choice is
'b.operator int()' if it is defined.

-- David R. Tribble, david.tribble@noSPAM.central.beasys.com --
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]