问题
The assignment operator can be overloaded using a member function but not a non-member friend function:
class Test
{
int a;
public:
Test(int x)
:a(x)
{}
friend Test& operator=(Test &obj1, Test &obj2);
};
Test& operator=(Test &obj1, Test &obj2)//Not implemented fully. just for test.
{
return obj1;
}
It causes this error:
error C2801: \'operator =\' must be a non-static member
Why cannot a friend function be used for overloading the assignment operator? The compiler is allowing to overload other operators such as += and -= using friend. What\'s the inherent problem/limitation in supporting operator=?
回答1:
Because the default operator= provided by the compiler (the memberwise copy one) would always take precedence. I.e. your friend operator= would never be called.
EDIT: This answer is answering the
Whats the inherent problem/limitation in supporting = operator ?
portion of the question. The other answers here quote the portion of the standard that says you can't do it, but this is most likely why that portion of the standard was written that way.
回答2:
Firstly, it should be noted that this has nothing to do with the operator being implemented as a friend specifically. It is really about implementing the copy-assignment as a member function or as a non-member (standalone) function. Whether that standalone function is going to be a friend or not is completely irrelevant: it might be, it might not be, depending on what it wants to access inside the class.
Now, the answer to this question is given in D&E book (The Design and Evolution of C++). The reason for this is that the compiler always declares/defines a member copy-assignment operator for the class (if you don't declare your own member copy-assignment operator).
If the language also allowed declaring copy-assignment operator as a standalone (non-member) function, you could end up with the following
// Class definition
class SomeClass {
// No copy-assignment operator declared here
// so the compiler declares its own implicitly
...
};
SomeClass a, b;
void foo() {
a = b;
// The code here will use the compiler-declared copy-assignment for `SomeClass`
// because it doesn't know anything about any other copy-assignment operators
}
// Your standalone assignment operator
SomeClass& operator =(SomeClass& lhs, const SomeClass& rhs);
void bar() {
a = b;
// The code here will use your standalone copy-assigment for `SomeClass`
// and not the compiler-declared one
}
As seen in the above example, the semantics of the copy-assignment would change in the middle of the translation unit - before the declaration of your standalone operator the compiler's version is used. After the declaration your version is used. The behavior of the program will change depending on where you put the declaration of your standalone copy-assignment operator.
This was considered unacceptably dangerous (and it is), so C++ doesn't allow copy-assignment operator to be declared as a standalone function.
It is true that in your particular example, which happens to use a friend function specifically, the operator is declared very early, inside the class definition (since that's how friends are declared). So, in your case the compiler will, of course, know about the existence of your operator right away. However, from the point of view of C++ language the general issue is not related to friend functions in any way. From the point of view of C++ language it is about member functions vs. non-member functions, and non-member overloading of copy-assignment is just prohibited entirely for the reasons described above.
回答3:
$13.5.3 - "An assignment operator shall be implemented by a non-static member function with exactly one parameter. Because a copy assignment operator operator= is implicitly declared for a class if not declared by the user (12.8), a base class assignment operator is always hidden by the copy assignment operator of the derived class."
回答4:
Because there are some operators which MUST be members. These operators are:operator[]operator=operator()operator->
and type conversion operators, like operator int.
Although one might be able to explain why exactly operator = must be a member, their argument cannot apply to others in the list, which makes me believe that the answer to "Why" is "Just because".
HTH
回答5:
operator= is a special member function that the compiler will provide if you don't declare it yourself. Because of this special status of operator= it makes sense ro require it to be a member function, so there is no possibility of there being both a compiler-generated member operator= and a user-declared friend operator= and no possibility of choosing between the two.
回答6:
Why friend function can't be used for overloading assignment operator?
Short answer: Just because.
Somewhat longer answer: That's the way the syntax was fixed. A few operators have to be member functions. The assignment operator is one of the,
回答7:
The intention of operator= is an assignment operation to the current object. Then the LHS, or lvalue, is an object of the same type.
Consider a case where the LHS is an integer or some other type. That is a case handled by operator int() or a corresponding operator T() function. Hence the type of the LHS is already defined, but a non-member operator= function could violate this.
Hence it is avoided.
回答8:
Because there is already an implicit operator overloading function for '=' in the class to do shallow copying. So even if you overload using a a friend function you will never be able to call it as any call made by us would call the implicit shallow copying method rather than the overloaded friend function.
回答9:
This post applies to C++11
Why would someone want a non-member operator=? Well, with a member operator= then the following code is possible:
Test const &ref = ( Test() = something );
which creates a dangling reference. A non-member operator would fix this:
Test& operator=(Test &obj1, Test obj2)
because now the prvalue Test() will fail to bind to obj1. In fact this signature would enforce that we never return a dangling reference (unless we were supplied with one, of course) - the function always returns a "valid" lvalue because it enforces being called with an lvalue.
However in C++11 there is now a way to specify that a member function can only be called on lvalues, so you could achieve the same goal by writing the member function:
Test &operator=(Test obj2) &
// ^^^
Now the above code with dangling reference will fail to compile.
NB. operator= should take the right-hand-side by either value or const reference. Taking by value is useful when implementing the copy and swap idiom, a technique for easily writing safe (but not necessarily the fastest) copy-assignment and move-assignment operators.
来源：https://stackoverflow.com/questions/3933637/why-cannot-a-non-member-function-be-used-for-overloading-the-assignment-operator