On 8/23/2011 8:06 AM, Julian Gonggrijp wrote: <snip>
PART I. I think the default templates header should look like this:
template <class T> struct underlying_type_traits { typedef T type; };
Only if T is a POD, so BOOST_MPL_ASSERT((is_pod<T>)) would be a useful addition here.
#define UNDERLYING_TYPE(T) underlying_type_traits< T >::type
template <class T> void move_raw (T& source, T& target) { target = source; }
template <class T> void move_raw (T& source, typename UNDERLYING_TYPE(T)& target) { target = source; }
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. 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.
// Not shown: partial specializations for arrays, like in Boost.Swap. // Possible refinement: partial specializations that disable // compilation for const types.
There are many good reasons to default to type identity and copy assignment:
1. it is optimal for PODs; 2. it works and is safe for copyable non-PODs;
No, it's not safe.
3. from 1. and 2.: the algorithms from part II. are automatically guaranteed to work for all types that can currently use the copy- based counterparts from the STL; 4. on top of 3., all algorithms from part II. are guaranteed to be always at least as efficient as their copy-based counterparts; 5. from 3. and 4.: raw_move::swap can directly replace std::swap as
What's raw_move::swap? -- Eric Niebler BoostPro Computing http://www.boostpro.com