14

Is the compiler allowed to eliminate the copy that is required for the by-value capture?

vector<Image> movie1;
apply( [=movie1](){ return movie1.size(); } );
  • Is there any circumstance that the compiler does not need to copy movie1?
    • Maybe if the compiler could know, that apply does not actually change movie1?
    • Or does it help that Lambdas are by default const functors in any case?
  • Does it help at all that vector has a move constructor and move assign?
    • If yes, is it required to add these to Image as well, to prevent an expensive copy here?
  • Is there a difference in the mechanism when and how a copy is required for by-value capture compared to by-value arguments? eg. void operate(vector<Image> movie)?
Fred Foo
  • 355,277
  • 75
  • 744
  • 836
towi
  • 21,587
  • 28
  • 106
  • 187

2 Answers2

9

I'm fairly sure it cannot.

Even if the outer function no longer explicitly uses the variable, moving the variable would change the semantics of destruction.

Having move constructors for Image doesn't help, a vector can move or swap without moving its elements.

If the variable is read-only from this point forward, why not capture by reference? You could even create a const reference and capture that.

If the variable is not read-only, the copy is required. It doesn't matter whether the outer function or the lambda performs the modification, the compiler cannot allow that modification to become visible to the other.

The only difference I see between by-value capture and by-value argument passing is that the capture is named, it cannot be a temporary. So argument passing optimizations applicable to temporaries cannot be used.

Ben Voigt
  • 277,958
  • 43
  • 419
  • 720
  • "why not capture by reference"? I am in the process of understanding all implications. I agree. "The only difference..." is a great answer. Perfect! – towi Mar 13 '11 at 16:03
3

There is always the "as-if" rule. As long as it looks as if the rules had been followed, the compiler can do whatever it likes. So for objects where the copy constructor and destructor have no side effects, and where no changes are made to the copy, or the original object isn't accessed afterwards (so no one will notice if we make changes to the object), the compiler could prove that eliminating the copy is legal under the "as-if" rule.

But other than that, no, it can't just eliminate the copy, as @Ben said. The "regular" copy elision rules don't cover this case.

jalf
  • 243,077
  • 51
  • 345
  • 550
  • Thats the term I was looking for: *copy elision*. Thanks for clarify that these can not applied here. Thx. – towi Mar 15 '11 at 09:57
  • Copy elision is not applicable here, as copy elision was introduced for situations where you are effectively "moving" the value (the original value can no longer be accessed - this is true both for copy initialization and return value). In case of lambda you can access the captured value both in the lambda and in the original context, therefore it is a true copy. – Suma Mar 15 '11 at 10:23