Why is the copy constructor called instead of the move constructor when returning?

Question

Let’s say I have the class MyClass with a correct move constructor and whose copy constructor is deleted. Now I am returning this class like this:

MyClass func()
{
    return MyClass();
}

In this case the move constructor gets called when returning the class object and everything works as expected.

Now let’s say MyClass has an implementation of the << operator:

MyClass& operator<<(MyClass& target, const int& source)
{
    target.add(source);
    return target;
}

When I change the code above:

MyClass func()
{
    return MyClass() << 5;
}

I get the compiler error, that the copy constructor cannot be accessed because it is deleted. But why is the copy constructor being used at all in this case?

Lightness Races in Orbit · Accepted Answer · 2019-06-25T10:24:49.490

Now I am returning this class via lvalue like this:
MyClass func()
{
    return MyClass();
}

No, the returned expression is an xvalue (a kind of rvalue), used to initialise the result for return-by-value (things are a little more complicated since C++17, but this is still the gist of it; besides, you're on C++11).

In this case the move constructor gets called when returning the class object and everything works as expected.

Indeed; an rvalue will initialise an rvalue reference and thus the whole thing can match move constructors.

When I change the code above:

… now the expression is MyClass() << 5, which has type MyClass&. This is never an rvalue. It's an lvalue. It's an expression that refers to an existing object.

So, without an explicit std::move, that'll be used to copy-initialise the result. And, since your copy constructor is deleted, that can't work.

I'm surprised the example compiles at all, since a temporary can't be used to initialise an lvalue reference (your operator's first argument), though some toolchains (MSVS) are known to accept this as an extension.

then would return std::move(MyClass() << 5); work?

Yes, I believe so.

However that is very strange to look at, and makes the reader double-check to ensure there are no dangling references. This suggests there's a better way to accomplish this that results in clearer code:

MyClass func()
{
    MyClass m;
    m << 5;
    return m;
}

Now you're still getting a move (because that's a special rule when returning local variables) without any strange antics. And, as a bonus, the << call is completely standard-compliant.

@RomCoo I believe so. However that is very strange to look at and suggests there's a better way to accomplish this. — Lightness Races in Orbit, Jun 25 '19 at 10:23
Is the expression `MyClass() << 5` valid? I don't think so! `gcc` and `clang` properly reject this expression. `mvc` accepts it ... You cannot bind rvalue to no`const` lvalue — BiagioF, Jun 25 '19 at 11:21

StoryTeller - Unslander Monica · Answer 2 · 2019-06-25T10:17:52.710

8

Your operator return by MyClass&. So you are returning an lvalue, not an rvalue that can be moved automatically.

You can avoid the copy by relying on the standard guarantees regarding NRVO.

MyClass func()
{
    MyClass m;
    m << 5;
    return m;
}

This will either elide the object entirely, or move it. All on account of it being a function local object.

Another option, seeing as you are trying to call operator<< on an rvalue, is to supply an overload dealing in rvalue references.

MyClass&& operator<<(MyClass&& target, int i) {
    target << i; // Reuse the operator you have, here target is an lvalue
    return std::move(target);
}

That will make MyClass() << 5 itself well formed (see the other answer for why it isn't), and return an xvalue from which the return object may be constructed. Though such and overload for operator<< is not commonly seen.

edited Jun 25 '19 at 10:17

answered Jun 25 '19 at 10:04

StoryTeller - Unslander Monica

148,497
21
320
399

Presumably he wanted to return the result of `operator< – David Schwartz Jun 25 '19 at 10:06
@DavidSchwartz - One can also presume `operator< – StoryTeller - Unslander Monica Jun 25 '19 at 10:08
But the lack of a `const` on the first parameter, at least to me, suggests otherwise. Also, that would really not be idiomatic. It'd be odd if `i<<3` returned `i`. – David Schwartz Jun 25 '19 at 10:08
@DavidSchwartz - That's quite a leap either way. I think we both hastened to answer instead of asking the OP for a better example. – StoryTeller - Unslander Monica Jun 25 '19 at 10:09
1

@DavidSchwartz - Not idiomatic, what? That's what stream operators do. – StoryTeller - Unslander Monica Jun 25 '19 at 10:09
Oh, that's true. I guess we can't really know which idiom is the right one, the one for stream operators or the one for shifts. Maybe you can argue the lack of a `const` argues in favor of the stream idiom. – David Schwartz Jun 25 '19 at 10:10
Yes `operator< – RomCoo Jun 25 '19 at 10:11
_"You can avoid the copy by relying on the standard guarantees regarding NRVO."_ Question is tagged C++11, so there aren't any. – Lightness Races in Orbit Jun 25 '19 at 10:22
@LightnessRacesinOrbit - [There is](https://timsong-cpp.github.io/cppwp/n3337/class.copy#32). – StoryTeller - Unslander Monica Jun 25 '19 at 10:23
@StoryTeller That's not NRVO. :) – Lightness Races in Orbit Jun 25 '19 at 10:24
@LightnessRacesinOrbit - Sure, that'd be paragraph 31 above the one I linked. Either way, the standard guarantees either elision, or a move. – StoryTeller - Unslander Monica Jun 25 '19 at 10:25
Yep, `return` of a local coerces its arg into an xvalue. But that produces a [potential] move, not an instance of NRVO, which is something different (total elision) which comes in C++17 (and was permitted for optimisers before that) – Lightness Races in Orbit Jun 25 '19 at 10:26
@LightnessRacesinOrbit - Total elision (c++17 style) concerns only returning prvalues (`return MyClass()` in the answer, for instance). NRVO as pertaining to named objects is all I was talking about. The "N" does stand for "named" after all :) – StoryTeller - Unslander Monica Jun 25 '19 at 10:28
@StoryTeller meanwhile all I can see is how close it is to `delete {new Foo()->thing()}` ... I'm very clearly broken. – UKMonkey Jun 25 '19 at 10:33
@UKMonkey - Not as broken as I was every time I saw such a thing in production code. I have since left that shop, and can even not squirm while looking at your comment :P – StoryTeller - Unslander Monica Jun 25 '19 at 10:38

score 1 · Answer 3 · answered Jun 25 '19 at 10:06

Your operator<< takes its first parameter as a non-const reference. You can't bind a non-const reference to a temporary. But MyClass() returns the newly-created instance as a temporary.

Also, while func returns a value, operator<< returns a reference. So what else can it do but make a copy to return?

Why is the copy constructor called instead of the move constructor when returning?

3 Answers3