What is the difference between the two forms of returning object?

Question

I was trying overloading binary + for an Integer class created as:

const Integer operator+(const Integer& left,const Integer& right) 
{
 return Integer(left.i + right.i);
}

and

 const Integer operator+(const Integer& left,const Integer& right)
 {
 Integer tmp(left.i + right.i);
 return tmp;
 }

Now what I learnt was that in the first case a temporary Integer object is created and is returned and in the second case the usual object creation using constructor call and then copying and then calling destructor takes place. What Ecekl has said for the first one is that the compiler takes advantage of this by building the object directly into the location of the outside return value.What do we infer from this ? I read about the return value optimization but couldn't get what it means by copying directly into the location thing.

• WhozCraig: Related: Any reason that return Integer must be const ??, Also, address your question, absolutely nothing provided NRVO was properly implemented by the compiler.
• Kavish Dwivedi: @WhozCraig:Actually I wanted something like (a+b).g() that is function call therefore I had to make the return value constant because in this case a+b would be a constant temporary .

Answer 1

There is absolutely no difference, and in most situations a decent compiler will optimize the second form into the first - and will perform copy/move elision by Named Return Value Optimization (NRVO) when returning tmp.

You might want to use the second form if it makes the code more readable for you, or easier to maintain and/or debug. If you are concerned with performance, there's no reason (unless you turned off compiler optimizations, but that would suggest you're not interested in performance in the first place).

Notice, however, that returning a const Integer does not make a lot of sense. Since you are returning by value, you should rather return an Integer:

Integer operator + (const Integer& left, const Integer& right) 
{
 return Integer(left.i + right.i);
}

As a final remark, this could even be rewritten as follows, provided that Integer has a non-explicit constructor accepting an int (notice, that this is usually not the case, since constructors accepting one argument are generally marked as explicit to avoid awkward implicit conversions):

Integer operator + (const Integer& left, const Integer& right) 
{
 return left.i + right.i;
}

• Matthieu M.: I would note, though, that you might not want a non-explicit constructor. It is annoying that implicit is the default... On a similar note, I've read about a proposal to make it so that return left.i + right.i; could be used even if Integer constructor was marked explicit. The reasoning being that specifying the return type was explicit enough.
• Andy Prowl: @MatthieuM.: Good point. I agree, normally constructors which take one argument and are not copy-constructors should be marked as explicit. On the other hand, in this case (an Integer wrapping an int), I guess it could make some sense, although I am far from saying it is a good programming practice. My intention was just to neutrally mention the fact, that if the constructor is not explicit, then the OP could omit the explicit creation.