I am a bit confused about the differences between
Type operator + (const Type &type); Type &operator += (const Type &type); and
friend Type operator + (const Type &type1, const Type &type2); friend Type &operator += (const Type &type1, const Type &type2); which way is preferred, what do they look like and when should either be used?
The first form of the operators is what you would define inside class Type.
The second form of the operators is what you would define as free-standing functions in the same namespace as class Type.
It's a very good idea to define free-standing functions because then the operands to those can take part in implicit conversions.
Assume this class:
class Type { public: Type(int foo) { } // Added the const qualifier as an update: see end of answer Type operator + (const Type& type) const { return *this; } }; You could then write:
Type a = Type(1) + Type(2); // OK Type b = Type(1) + 2; // Also OK: conversion of int(2) to Type But you could NOT write:
Type c = 1 + Type(2); // DOES NOT COMPILE Having operator+ as a free function allows the last case as well.
What the second form of the operator does wrong though is that it performs the addition by directly tweaking the private members of its operands (I 'm assuming that, otherwise it would not need to be a friend). It should not be doing that: instead, the operators should also be defined inside the class and the free-standing functions should call them.
To see how that would turn out, let's ask for the services of a guru: http://www.gotw.ca/gotw/004.htm. Scroll at the very end to see how to implement the free-standing functions.
Update:
As James McNellis calls out in his comment, the two forms given also have another difference: the left-hand-side is not const-qualified in the first version. Since the operands of operator+ should really not be modified as part of the addition, it's a very very good idea to const-qualify them all the time. The class Type in my example now does this, where initially it did not.
The best way to deal with operators + and += is:
operator+= as T& T::operator+=(const T&); inside your class. This is where the addition would be implemented.operator+ as T T::operator+(const T&) const; inside your class. This operator would be implemented in terms of the previous one.T operator+(const T&, const T&); outside the class, but inside the same namespace. This function would call the member operator+ to do the work.You can omit step 2 and have the free function call T::operator+= directly, but as a matter of personal preference I 'd want to keep all of the addition logic inside the class.
operator+). This is what I 'm saying.
+ in terms of +=. Your answer recommends doing it the other way around. (The GOTW you link agrees with Daniel.)
T& T::operator+=(T const&); and T operator+(T lhs, T const& rhs) { return lhs += rhs; } --> your step 2. is spurious, your signature is off in step 3. (compiler can optimize the copy in function signature better, especially with the upcoming move semantics)The proper way to implement operators, with respect to C++03 and C++0x (NRVO and move-semantics), is:
struct foo { // mutates left-operand => member-function foo& operator+=(const foo& other) { x += other.x; return *this; } int x; }; // non-mutating => non-member function foo operator+(foo first, // parameter as value, move-construct (or elide) const foo& second) { first += second; // implement in terms of mutating operator return first; // NRVO (or move-construct) } Note it's tempting to combine the above into:
foo operator+(foo first, const foo& second) { return first += second; } But sometimes (in my testing) the compiler doesn't enable NRVO (or move semantics) because it can't be certain (until it inlines the mutating operator) that first += second is the same as first. Simpler and safer is to split it up.
+= and +) what a = a + b would give ? I don't understand how NRVO could kick in here, since if += were to throw, then a is supposedly unmodified.
The friend specifier is used when the thing being declared isn't a member of the class, but needs access to the private members of the class's instances in order to do its job.
If your operator will be defined in the class itself, use the first way; if it'll be a standalone function, use the second.
In many cases, you write operators against a class type T within the class. Mostly as a convention. However, as noted in Jon's answer, free-standing functions can help in resolving certain cases without the need for more implementations.
There is also another important case I wanted to mention: a class exists and it does not support a certain operator that you would like to have.
Here is an example:
std::string & operator += (std::string & lhs, char32_t rhs) { lhs += (...rhs converted to UTF-8...); return lhs; } The system does not have that operator defined, so having the ability to add it in your own header and allowing the automatic conversion of the rhs from a Unicode character to UTF-8 is very practical if you have many functions doing such all over the place.
In this case, you do not have a choice but for a free-standing function since you can't just extend an existing class you do not control.
Functional examples in my libutf8 library: https://github.com/m2osw/libutf8/blob/c516aa954004cbbaca401e6aba3eb867fd329acd/libutf8/libutf8.h#L89-L132
T operator+(const T& t) const;.friendkeyword has no direct relation to the issue and can only add to the confusion. There's absolutely no requirement for a standalone operator to be declared as afriend. Even though you one can often hear this approach referred to as "declaring operator as a friend", the reference to friendship in this context is a confusing misnomer.friendnot because of anything to do with access control, but simply because that's the way to put the definition of a non-member function inside a class definition. So in that situation the two issues are related.operator+should takeconstfor its first operand, andoperator+=definitely shouldn't.