I have a question about the return value of operator overloading in C++. Generally, I found two cases, one is return-by-value, and one is return-by-reference. So what's the underneath rule of that? Especially at the case when you can use the operator continuously, such as cout<<x<<y.
For example, when implementing a + operation "string + (string)". how would you return the return value, by ref or by val.
Some operators return by value, some by reference. In general, an operator whose result is a new value (such as +, -, etc) must return the new value by value, and an operator whose result is an existing value, but modified (such as <<, >>, +=, -=, etc), should return a reference to the modified value.
For example, cout is a std::ostream, and inserting data into the stream is a modifying operation, so to implement the << operator to insert into an ostream, the operator is defined like this:
std::ostream& operator<< (std::ostream& lhs, const MyType& rhs)
{
// Do whatever to put the contents of the rhs object into the lhs stream
return lhs;
}
This way, when you have a compound statement like cout << x << y, the sub-expression cout << x is evaluated first, and then the expression [result of cout << x ] << y is evaluated. Since the operator << on x returns a reference to cout, the expression [result of cout << x ] << y is equivalent to cout << y, as expected.
Conversely, for "string + string", the result is a new string (both original strings are unchanged), so it must return by value (otherwise you would be returning a reference to a temporary, which is undefined behavior).
<< does not modify the existing value. It's just a left-shift operator. It's the stream interface breaking the rules. –
Kathie operator<<) where the overload is implemented as a non-member. –
Apprehension <<=? :p) –
Kathie operator<< is a left shift and doesn't modify the original so it should return by value; when applied to a stream it does modify the stream so it should return by reference. –
Applejack stringstream). Its "value" is very much implementation dependent, and is not the same as the state of the resource that it connects to. –
Applejack int, whether they modify the object or produce a copy with a new value, and then follow the rules given in this answer. Spoiler: you should by reference for the prefix operators, which return modifiable lvalue references to the original object with its after-(inc|dec)remented value - and by value for the postfix forms, which return copies of the object with its original value (i.e. not the new value that it, itself, now has). –
Chagrin To attempt an answer to your question regarding strings, the operator+() for strings is almost always implemented as a free (non-member) function so that implicit conversions can be performed on either parameter. That is so you can say things like:
string s1 = "bar";
string s2 = "foo" + s1;
Given that, and that we can see that neither parameter can be changed, it must be declared as:
RETURN_TYPE operator +( const string & a, const string & b );
We ignore the RETURN_TYPE for the moment. As we cannot return either parameter (because we can't change them), the implementation must create a new, concatenated value:
RETURN_TYPE operator +( const string & a, const string & b ) {
string newval = a;
newval += b; // a common implementation
return newval;
}
Now if we make RETURN_TYPE a reference, we will be returning a reference to a local object, which is a well-known no-no as the local object don't exist outside the function. So our only choice is to return a value, i.e. a copy:
string operator +( const string & a, const string & b ) {
string newval = a;
newval += b; // a common implementation
return newval;
}
a is constructed by the call) to simply take a by value and modify/return that, rather than needing any other intermediate string. Generally, if you need to copy an argument, take it by value: that's getting a copy for free. So those 3 lines are simplified to return a += b;. @user: The mistake there was thinking about "freeing" and "allocation" at all. The whole point of RAII and classes like std::string is to avoid the end user having to worry about freeing. Just use the result and let RAII KO it –
Chagrin If you want your operator overload to behave like the built-in operator, then the rule is pretty simple; the standard defines exactly how the built-in operators behave and will indicate if the result of a built-in is an rvalue or an lvalue.
The rule you should use is:
rvalue then your overload should return a referencelvalue then your overload should return a valueHowever, your overload isn't required to return the same kind of result as the built-in, though that's what you should do unless you have a good reason to do otherwise.
For example, KennyTM noted in a comment to another answer that the stream overloads for the << and >> operators return a reference to the left operand, which is not how the built-ins work. But the designers of the stream interface did this so stream I/O could be chained.
ints Do! –
Chagrin Depending on the operator you may have to return by value.
When both can be used though, like in operator+= you could consider the following:
operator+= is to mutate the object. It should not be called on immutable objects. –
Degeneration Usually you return by reference in an operation that changes the value of the things it's operating on, like = or +=. All other operations are return by value.
This is more a rule of thumb, though. You can design your operator either way.
ints do" is generally the best advice. Obviously, this isn't always 100% feasible (although my mind has just gone blank of examples), or sometimes you're doing something wild like ostream.operator<< or path.operator/... but in most cases, the int-style behaviour is both possible & desirable. You "can" do "either way" - but chances are you'll just annoy users if you flip them! –
Chagrin © 2022 - 2024 — McMap. All rights reserved.