Eric Niebler wrote:
On 8/23/2011 8:06 AM, Julian Gonggrijp wrote: <snip>
[...] template <class T> void move_raw (typename UNDERLYING_TYPE(T)& source, T& target) { target = source; }
Yikes, no. T's copy constructor can throw. This should be a move, and then only if T's move assign cannot throw. Otherwise, move_raw should probably be undefined.
If move_raw is implemented as a copy, it doesn't really matter if the copy throws because the source object is left in a valid state, right? I mean, with the copy-based swap we usually also don't worry about the possibility that one of the copies might throw...
You may decide to provide an easy way for users to opt-in for a memcpy based solution, but that option should only be available only on compilers for which memcpy-ing non-PODs is empirically known to work. And there should be a warning about the non-portability about doing that.
If you are right and using copy as a fallback for raw moves is not an option, it means a significant loss of generality. Adding an opt-in for a memcpy hack will give only a very small relief. But perhaps such a less-general tool can still have its use.
What's raw_move::swap?
It was an improvised shorthand for 'the swap algorithm that is implemented with raw moves'. -Julian