3 ms·
> So the code only works because the author uses array, which is statically allocated and there is nothing to steal. It would break were they to switch to vecto
by tylerhou 6y ago
> So the code only works because the author uses array, which is statically allocated and there is nothing to steal. It would break were they to switch to vector.
No, because get_display_pixels returns by value and not by reference. So the move constructor will move from a newly constructed value, not the instance gfx variable.
If get_display_pixels returned by mutable reference and the author used std::vector, yes, the code might break.
Nit: array is not statically allocated; it's stack/automatically allocated.
- w0utert 6y agoIt would not break, but it’s still a logical fallacy to std::move something returned by value, no? Or is there a valid use case here? I strictly use std::move in case of explicit transfer of ownership, and not to try to outsmart the compiler to ‘optimize’ something. As the article shows the compiler is smart enough to do all this by itself, it doesn’t need to be told to try to elide copies. But maybe I’m missing some valid use case where it would make sense to add the std::move in these kinds of situations?
- tylerhou 6y agoYou're right, there's not really a point in std::move-ing something returned by value because the something is already a rvalue.
- jfkrorkt 6y agoYou are right, the move is after the function returns (a copy). Thanks for pointing it out. Btw, that's what I meant by statically allocated, I wasn't sure what's the proper terminology.