Can you explain to me the difference between returning value, reference to value, and const reference to value?
Value:
Vector2D operator += (const Vector2D& vector)
{
this->x += vector.x;
this->y += vector.y;
return *this;
}
Not-const reference:
Vector2D& operator += (const Vector2D& vector)
{
this->x += vector.x;
this->y += vector.y;
return *this;
}
Const reference:
const Vector2D& operator += (const Vector2D& vector)
{
this->x += vector.x;
this->y += vector.y;
return *this;
}
What is the benefit of this? I understand the sense behind const reference passing to function as you want to make sure not to modify this value on which reference is pointing to inside a the function. But I'm confused by the meaning of returning const reference. Why returning of reference is better than returning of value, and why returning of const reference is better than returning of not-const reference?
It is exactly the same as passing argument to the function.
You want to return a
const
reference when you return a property of an object, that you want not to be modified out-side of it. For example: when your object has a name, you can make following methodconst std::string& get_name(){ return name; };
. Which is most optimal way. You allow a "read-only" access to an internal property, with out copy-on-return.When you are overloading operators you are expected to return an object that is mutable, otherwise some certain syntax that is usually expected to work will produce errors. It is quite important when you try some weird chaining.
For example option 3 will not work with something like
(v1 += v2).non_const_method()
, While, the following would:Value:
Returning by value means that you are returning a copy of an object. This puts requirements on the class (it has to be copyable or moveable). This means that for object of some classes returning by value may be expensive (in a case where RVO or NRVO does not work or is switched off). This also means that the new object is independent (subject to its design) from other objects and is a value of its own. This is what you probably should return from many binary operators like +, -, * and so on.
Non-const reference:
You really return an alias for another object. The alias being non const allow you to modify aliased object. This is what you should return from some unary oprators like prefix ++ and --, and * (dereference) as you usually want to have the ability to modify returned object.
This is returned by operator>> and operator<< overloaded for streams. This allows chaining of operators:
You can also return reference to *this when you want to allow chaining of regular methods like this:
Const reference:
Like above but you CANNOT modify aliased object. May be used instead of returning by value when the object to be returned is expensive to copy and when you can ensure its existence after you return from a function.
This is what operator= usually returns to allow multiple assignments in a way standard types support them:
Const-reference used in operator= prevents this kind of usage (not supported by standard type as far as I remember):
which would be allowed if normal reference was used.
The difference between return-by-value and return-by-reference takes effect during run-time:
When you return an object by-value, the copy-constructor is called, and a temporary instance is created on the stack.
When you return an object by-reference, all the above does not take place, leading to improved performance.
The difference between return-by-reference and return-by-constant-reference has no run-time effect, and is simply there to protect you from writing erroneous code.
For example, with
Vector2D& operator += (const Vector2D& vector)
, you can do:(x+=y)++
or(x+=y).func()
wherefunc
is a non-const function in classVector2D
.But with
const Vector2D& operator += (const Vector2D& vector)
, the compiler will generate an error for any such similar attempt.There is no difference unless you write something weird like
In the first case, the assignment will be to a temporary, and the overall effect will be
v1 += v2
.In the second case, the assignment will be to
v1
, so the overall effect will bev1 = v3
.In the third case, the assignment won't be allowed. This is probably the best option, since such weirdness is almost certainly a mistake.
It's potentially more efficient: you don't have to make a copy of the object.
You prevent weirdness like the above example, while still allowing less weird chaining such as
But, as noted in the comments, it means that your type doesn't support the same forms of (ab)use as the built-in types, which some people consider desirable.
As pointed out but luk32 it is just to ensure that no changes are allowed to the objects returned by this function. This can basically help you in finding your logical errors at compile time. Suppose you are sure not to change a object, and your code is changing the object, it can be tracked. It can be thought of a good coding practice.