Hacker News Reader

Comment by Sirenos | Hacker News Reader

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.

View on HN

Presumably this is why his final output consisted of

  constructor.
  destructor.
  move constructor
  destructor.

i.e. the data destructed before it was moved.

It'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).

In the last snippet the function returns BigObject&&.

I'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.

Oh my goodness. I'll blame that one on recovering from a bad cold.

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

The '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!

It's a safe, but inappropriate, use of std::move, which is kind of the point of the article ;)

Reply on news.ycombinator.com