What is the purpose of returning a reference in overloding =operator

Question

I wondered why we should return a reference, when we overload operator = (assignment). On the one hand, most of the examples that I've seen (of overloading operator =), return a reference, but on the other hand, I saw few examples (of the same subject) that don't return a reference.

Can someone explain me, when we need to return a reference (specifically in operator = overloading), and give examples?

Answer 1

The main reason for returning a reference in operator= is because the old Assignable property for C++03 collection items, required it.

There is a corresponding requirement in C++11.

These requirements stemmed from the built-in operator=, which in turn got it from C, where it supported assignment chaining, e.g. writing

a = b = 666;

which is parsed as

a = (b = 666);

For a user-defined operator= it

• is less efficient,

• often more complex (e.g. for an iterator implementation) and

• opens the door to Unholy Practices™ based on side-effects,

and so for a long time, until someone directed my attention to the standard library's requirements, I just defined operator= as returning void. More efficient, less verbose, no support for bad practices. But with such a requirement – it's yet another bad case of Frozen History™ – one simply must.

• ikegami: a = (b = 666); doesn't require an lvalue/reference to be returned by the assignment. As the previous answer mentioned, it's (a = b) = 666; that does.
• Cheers and hth. - Alf: @ikegami: right, but it supports it. if you want to get really down to fundamental causes, one may surmise that original C attempted to leverage use of an address already loaded in a register. a value such as 666 might be part of the instruction, not very reusable.
• Guy: So the main propose of returning a reference is its' assignment chaining advantage? Can you give me also an example when an =operator overloading works without a reference? Thanks!
• Mike Seymour: @ikegami: For some types, support for chaining (or otherwise using the value) does require a reference. The alternative is to return a copy of the result, and not all types are copyable.
• ikegami: @Cheers and hth. - Alf, It also supports addition, neither of which has to do with the question.

Answer 2

Returning a reference returns a modifiable value (lvalue). It allows the following:

(a = b) = c;

Ok, that one's a bit silly, but this one makes more sense:

++(a = b);

• Guy: Can you give me also an example when an =operator overloading works without a reference? Thanks! @ikegami
• ikegami: @Guy, In x = (y = 4);, the value returned by the inner assignment doesn't need to be modifiable since nothing writes to it, and the value returned by the outer assignment doesn't need to be modifiable since it's discarded.
• Guy: @ikegami I think I've understood, thanks. One more question/request : Can you give me an example which doesn't work without reference?
• ikegami: @Guy, The two in my answer.
• ikegami: I'll give you a Perl example that really illustrates the principle. In Perl 5.14+, you can use $new = $old =~ s/.../.../r; to perform a substitution on variable $old and store the result in $new. But before 5.14, substitutions were always done in-place, so you'd have to use the following to get the same effect: $new = $old; $new =~ s/.../.../; But since the assignment operator returns an lvalue (reference), you could write that as ($new = $old) =~ s/.../.../;

Answer 3

One reason is because of efficiency. By passing and returning references in overloading the assignment operator, you prevent a lot of constructors and copy constructors from being called.

• Guy: Oh, because it isn't passing by value? Thank you.
• Lawrence Aiello: Right. If you pass by value, the function needs to create a copy of whatever you passed in, so it calls a constructor and a copy constructor for that value.