转载自：

https://stackoverflow.com/questions/2337213/return-value-of-operator-overloading-in-c

 

Operator overloading : member function vs. non-member function?

问题：

I read that an overloaded operator declared as member function is asymmetric because it can have only one parameter and the other parameter passed automatically is the this pointer. So no standard exists to compare them. On the other hand, overloaded operator declared as a friend is symmetric because we pass two arguments of the same type and hence, they can be compared.

My question is that when i can still compare a pointer's lvalue to a reference, why are friends preferred? (using an asymmetric version gives the same results as symmetric) Why do STL algorithms use only symmetric versions?

 

回答：

If you define your operator overloaded function as member function, then the compiler translates expressions like s1 + s2 into s1.operator+(s2). That means, the operator overloaded member function gets invoked on the first operand. That is how member functions work!

But what if the first operand is not a class? There's a major problem if we want to overload an operator where the first operand is not a class type, rather say double. So you cannot write like this 10.0 + s2. However, you can write operator overloaded member function for expressions like s1 + 10.0.

To solve this ordering problem, we define operator overloaded function as friend IF it needs to access private members. Make it friend ONLY when it needs to access private members. Otherwise simply make it non-friend non-member function to improve encapsulation!

class Sample { public: Sample operator + (const Sample& op2); //works with s1 + s2 Sample operator + (double op2); //works with s1 + 10.0 //Make it `friend` only when it needs to access private members. //Otherwise simply make it **non-friend non-member** function. friend Sample operator + (double op1, const Sample& op2); //works with 10.0 + s2 }

具体可参考：

http://users.monash.edu/~jonmc/CSE2305/Topics/10.19.OpOverload/html/text.html#a_slight_problem_of_ordering

A slight problem of ordering

Because C++ translates expressions like <var> <op> <value> into <var>.operator<op>(<value>), there's a major problem if we want to overload an operator where the first operand isn't a class¤ type.  For example, suppose we wanted to be able to add Coefficient objects together (producing new Coefficient objects). We could write: class Coefficient { public: // ...AS BEFORE... Coefficient operator+ (Coefficient c) { Coefficient sum (this->myValue + c.myValue); return sum; } Coefficient operator+ (double d) { Coefficient sum (this->myValue + d); return sum; } private: // ...AS BEFORE... }; ...which would allow us to write: Coefficient c1 (0.25); Coefficient c2 (0.45); Coefficient c3 (0.5); c3 = c1 + c2; // REALLY: c3.operator=(c1.operator+(c2)); // CALLS: Coefficient::operator+(Coefficient) c3 = c1 + 0.4; // REALLY: c3.operator=(c1.operator+(0.4)); // CALLS: Coefficient::operator+(double) // BUT NOT... c3 = 0.4 + c1; // CAN'T CALL (0.4).operator+(c1) !!!