Move rules

W

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
 
A

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
 
S

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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

Want to debug this? 14
Compiler related topics 3
String building 14
Can't think of a good subject 15
OS X compiler 5
OT: Problem building libc++ 7
Overloaded operator question 2
Marshalling asymmetry 8

Members online

Forum statistics

Threads
473,744
Messages
2,569,479
Members
44,899
Latest member
RodneyMcAu

Latest Threads

Top