Move rules

[woodbrian77]

I recall reading a month or so ago about how the standard
allows compilers to move an object that's about to go
out of scope. So iirc it wouldn't be necessary to use
std::move in that case. Now I'm not able to find anything
about that. Links please. And what compilers have
support for that?

I have some code like this

{
A a;
...
vec.emplace_back:std::move(a));
}

With clang 3.3 and gcc 4.8.1 my executable is smaller with
the std;;move than if I take that out. Does that mean that
those compilers aren't making that optimization? Tia.

Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net

 

[Alf P. Steinbach]

I recall reading a month or so ago about how the standard
allows compilers to move an object that's about to go
out of scope.

That's a *possible* optimization.

So iirc it wouldn't be necessary to use
std::move in that case. Now I'm not able to find anything
about that. Links please. And what compilers have
support for that?

As far as I know it's not part of C++11 other than being implicitly
allowed by the "as if" rule. However, under that rule the compiler has
to prove rigorously that the optimization yields the same logical
behavior as without it. And that can be a daunting task.

However, you as a programmer can more easily know that it's safe,
bringing to bear your understanding of the higher level logic and
constraints, and then explicitly apply this optimization (as you did).

And in some cases it can, for example, reduce O(n^2) behavior to O(n),
as I pointed out in the discussion (?) that Andrew Koenig and I recently
had in the comments to his blog in Dr. Dobbs Journal. Maybe that's where
you saw it. Or maybe some third party's reference to it.

I have some code like this

{
A a;
...
vec.emplace_back:std::move(a));
}

With clang 3.3 and gcc 4.8.1 my executable is smaller with
the std;;move than if I take that out. Does that mean that
those compilers aren't making that optimization?

Probably, yes.

If it matters, then check in a debugger.


Cheers & hth.,

- Alf

 

[sg]

Am 06.11.2013 18:02, schrieb (e-mail address removed):

I recall reading a month or so ago about how the standard
allows compilers to move an object that's about to go
out of scope. So iirc it wouldn't be necessary to use
std::move in that case. Now I'm not able to find anything
about that. Links please. And what compilers have
support for that?

I have some code like this

{
A a;
...
vec.emplace_back:std::move(a));
}

You remembered wrong. A compiler is not allowed to use the move
constructor here (unless it can prove under the as-if rule that it does
not make any difference w.r.t. side effects).

The only places where a compiler is allowed (and required!) to do an
implicit move is where it is already allowed to elide a copy but is not
able to do the copy elision for some reason. That is: returning a
function-local object and initializing some object with a temporary one.
That's it. And in those two cases, you should NOT use std::move because
that would just basically disable the copy elision optimization that
modern compilers tend to do.

sg