3 ms·
Someone correct me if I am wrong but isn't that last snippet where he returns std::move(localObj) essentially returning an rvalue-ref to a local object? That's
by Sirenos 11y ago
Someone correct me if I am wrong but isn't that last snippet where he returns std::move(localObj) essentially returning an rvalue-ref to a local object? That's like a big no-no because the local object destructs after foo(1) returns.
- a8da6b0c91d 11y agoIt's definitely an appropriate use of std::move. When the local object destructs std::move has already ripped its guts out and put them in the object up the stack. The local object is just an empty shell at destruction.
- nly 11y agoIt's a safe, but inappropriate, use of std::move, which is kind of the point of the article ;)
- seabee 11y agoThe 'object up the stack' is an rvalue reference. While we've successfully returned a reference into the caller's stack frame (RVO), the object it referred to has already been destroyed. That's why you see 'constructor, destructor' before 'move constructor'. I'm struggling to see how it's an appropriate use of std::move in any case where you actually use the rvalue reference!
- tomjakubowski 11y agoIt'd be a problem if the function returned BigObject&&, but since it returns BigObject the move happens inside the function body which should be fine (modulo the issues raised in the article).
- seabee 11y agoIn the last snippet the function returns BigObject&&.
- jayrhynas 11y agoI'm not sure if he updated the article since you read it, but he does have a note about that: > Note: We should not use this way in the real development, because it is a reference to a local object. Here just show how to make RVO happened.
- tomjakubowski 11y agoOh my goodness. I'll blame that one on recovering from a bad cold.
- deleted 11y ago[deleted]
- eridius 11y agoPresumably this is why his final output consisted of constructor. destructor. move constructor destructor. i.e. the data destructed before it was moved.