Assigning an object variable to a constant reference

Hi,

Can someone please explain to me exactly what happens when line
Rational result = left;
is executed?

Code:

---

Rational operator+ (const Rational & left, const Rational & right)
{
    Rational result = left;
    result += right;
    return result;
}

---

Note: in the user-defined class Rational, the assignment operator has not been redefined and no copy constructor has been defined either.

Thanks,

- Canadian

Quote:

---

Can someone please explain to me exactly what happens when line
Rational result = left;
is executed?

---

The Rational object named result is copy constructed.

Quote:

---

Note: in the user-defined class Rational, the assignment operator has not been redefined and no copy constructor has been defined either.

---

If the copy constructor is not explicitly declared and yet an object is copy constructed, the compiler will implicitly define the copy constructor. Likewise for the copy assignment operator.

Incidentally, you could also have written:

Code:

---

Rational operator+ (const Rational & left, const Rational & right)
{
    return Rational(left) += right;
}

---

or:

Code:

---

Rational operator+ (Rational left, const Rational & right)
{
    return left += right;
}

---

>> the compiler will implicitly define the copy constructor <<

Just to add, the compiler's implicitly defined copy functions do a member-wise copy. That's good enough for most classes, which is why classes don't do their own copying.

Quote:

---

Originally Posted by laserlight

The Rational object named result is copy constructed.

---

I'm sure that's what the optimizer turns it into, but I thought that line (without any optimization) would default construct a Rational object, then assign left to it?
To copy construct it, wouldn't you need to do this:

Code:

---

Rational result( left );

---

Quote:

---

Originally Posted by cpjust

I'm sure that's what the optimizer turns it into, but I thought that line (without any optimization) would default construct a Rational object, then assign left to it?
To copy construct it, wouldn't you need to do this:

Code:

---

Rational result( left );

---

---

The example from the standard:

Code:

---

class X {
    // ...
public:
    X(int);
    X(const X&, int = 1);
};

X a(1); // calls X(int);
X b(a, 0); // calls X(const X&, int);
X c = b; // calls X(const X&, int);

---

Edit: A constructor marked explicit wouldn't work for the = sign, true.

Indeed, there is no copy assignment involved, despite the appearance of the "=" lexeme.

Of course, if the copy constructor has been (explicitly) declared explicit then this syntax is not available, but Canadian0469 stated that the copy constructor was not explicitly declared.

Quote:

---

Originally Posted by cpjust

I'm sure that's what the optimizer turns it into, but I thought that line (without any optimization) would default construct a Rational object, then assign left to it?

---

Nope. If the = appears in the declaration, it marks an initializer expression, not an assignment operator. Thus, T t(e); and T t = e; are very closely related. Both are initializations. The first is called "direct-initialization", the second "copy-initialization". The differences between the two are very subtle, and only relevant for user-defined types with custom constructors.

So I guess all these years I've been creating strings like this:

Code:

---

std::string str( "Hello World" );

---

because I thought it was a little more efficient than:

Code:

---

std::string str = "Hello World";

---

When it actually didn't make any difference?

Well, the former constructs str with the string literal.

The latter, conceptually, constructs a temporary std::string with the string literal, then uses the copy constructor to construct str. But the implementation is allowed to elide the copy, and I think all compilers do this even with optimizations turned off.

The point is, nowhere is an assignment operator involved.

Quote:

---

Originally Posted by cpjust

So I guess all these years I've been creating strings like this:

Code:

---

std::string str( "Hello World" );

---

because I thought it was a little more efficient than:

Code:

---

std::string str = "Hello World";

---

When it actually didn't make any difference?

---

But did you really think the compiler would not optimize it away anyway in Release mode?
As CornedBee kindly points out, it hardly makes a difference. Visual Studio does not create any temporary, at the very least. It just does not work with constructors taking more than one argument.

Well even if it isn't more efficient, I guess I'll keep using construction vs assignment, since it just looks more natural for me. ;)

Whatever fancies you ;)
Or maybe, whatever rocks your boat!
I like the assignment form better, though.

If it wasn't for the silly "int i(); means I just created a function called i returning an int" issue, I'd prefer the constructor syntax.

Quote:

---

Originally Posted by Daved

If it wasn't for the silly "int i(); means I just created a function called i returning an int" issue, I'd prefer the constructor syntax.

---

That only applies to empty parentheses though, so even if that didn't declare a function, I don't see much point in adding the () there.

>> That only applies to empty parentheses though

No it doesn't. I believe there are other circumstances it happens as well. Besides, adding parentheses for the int means it is initialized to 0.

It applies when you want to construct temporaries in the argument list, and these temporaries take one argument, where you pass a single identifier, or no argument. Then it is interpreted as a function taking arguments of the types of the temporaries, those arguments either unnamed or with the name you specified.

Wow, those are illegible sentences.

for performance sake, dont return user-defined types by value. Instead make a free-operator function that takes three arguments like so

Code:

---

void func(Obj& returnValue, const Obj& obj1, const Obj& obj2);

---

Bah.

First, prove to me that the return-by-value is an actual performance problem. Then you may introduce the uglification of the interface.

I concur with CornedBee. Many times the performance hit is negligible. And other times, it is even optimized away.