4 ms·

Am I right to say that using std::move is even a logical mistake here? The purpose of move is to "steal" the underlying memory, but if you do that, you leave t

Am I right to say that using std::move is even a logical mistake here? The purpose of move is to "steal" the underlying memory, but if you do that, you leave the gfx variable from the class without backing. So basically you would need to reallocate it after every call to get_display_pixels. 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. Either the author doesn't understand what the purpose of move is, or if this is really their intent, it's a terrible design, since get_display_pixels looks like an idempotent getter function, but it's not.

foota 6y ago
Move leaves the object in a valid but unspecified state. So you can continue to use the existing object.
w0utert 6y ago
Yes that was what I was thinking as well, std::move on the return value of a function that returns some private member by value makes no sense (someone please correct me if I’m mistaken here). In the example in the article, the compiler may be able to perform all kinds of optimizations for example because the result is assigned to a const lvalue, and depending on the rest of the code in that function (which is not shown) it may be able to infer the assigned variable can never be aliased, so that’s one possible reason why the disassembly may be surprising. The C++ specification only prescribes how code should behave but it explicitly does not put restrictions how the compiler achieves that effect, to the point whole functions might be completely absent in the produced binary and replaced by a constant if it's possible to calculate the result of every invocation at compile time.
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 ago
  It 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 ago
    You'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 ago
  You 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.

foota 6y ago

Move leaves the object in a valid but unspecified state. So you can continue to use the existing object.

w0utert 6y ago

Yes that was what I was thinking as well, std::move on the return value of a function that returns some private member by value makes no sense (someone please correct me if I’m mistaken here). In the example in the article, the compiler may be able to perform all kinds of optimizations for example because the result is assigned to a const lvalue, and depending on the rest of the code in that function (which is not shown) it may be able to infer the assigned variable can never be aliased, so that’s one possible reason why the disassembly may be surprising. The C++ specification only prescribes how code should behave but it explicitly does not put restrictions how the compiler achieves that effect, to the point whole functions might be completely absent in the produced binary and replaced by a constant if it's possible to calculate the result of every invocation at compile time.

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 ago
It 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 ago
  You'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 ago
You 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.