Re: [boost] [proposal] raw move (was: [interest] underlying type library)

Subject: Re: [boost] [proposal] raw move (was: [interest] underlying type library)
From: Julian Gonggrijp (j.gonggrijp_at_[hidden])
Date: 2011-08-23 14:13:15

Nevin Liber wrote:

> In the C++11 move case, the moved-from object itself doesn't know if it is
> about to be destroyed or reused, so it has to be put in a state where either
> can happen.

Excuse me, but that doesn't seem logical. You are saying that since 
the object doesn't know what is going to happen, the programmer has to 
prepare it for both scenarios. But in this case the programmer knows 
what is going to happen (assuming that care is taken to ensure 
exception-safety). So it can just as well prepare the object only for 
the scenario that is really going to happen.

>  The compiler, of course, knows, and I want the optimizer to
> take advantage of this.
> 
> [As a parallel:  I still write a correct copy constructor for a copyable
> object even if all my uses involve RVO and it never gets called; as I'd
> rather have correct but slower code than incorrect code if a non-RVO case
> happens to pop up.]

You are giving a valid reason for implementing a copy constructor, but 
the argument is orthogonal to the point I was trying to make. Suppose 
you have not only copy constructors at your disposal but also a tool 
that is guaranteed to do RVO (e.g. something along the line of rvalue 
references). Then surely every time you use a function that returns a 
local variable you are going to use the RVO-only tool and not the 
most-of-the-time-optimized-into-RVO copy constructor?

> raw_move is a user optimization over C++11 moves in that it assumes the
> moved-from object is going to be reused; destruction would be very bad,
> which is why there is all this worry over exception safety.

So far I understood. What I didn't see was why an exception would be 
bad if the moved-from object is actually in a valid state because 
behind the scenes move_raw is implemented as a copy. Eric Niebler has 
enlightened me: it's not bad for the object itself, but it might be a 
disaster for another object which has undergone a real raw move before the exception happened.

-Julian