on Thu Apr 30 2009, Sebastian Redl <sebastian.redl-AT-getdesigned.at> wrote:
David Abrahams wrote:
Hi Ion,
are you familiar with http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2855.html ?
Until the committee decides exactly how to handle it and compilers catch up with the feature they add, we need a workaround for that problem, both for C++03 and C++0x. The simplest approach requires a trait called has_nothrow_move<T> which can be used to SFINAE-out pair's move constructor unless its members all have a nonthrowing move constructor. It would be reasonable to say
template <class T> struct has_nothrow_move : has_move_constructor {};
as a default, since move constructors shouldn't throw. But still, we need an implementation of has_move_constructor. Obviously, that will require compiler support to be optimal, but in the meantime it can be specialized.
What if we say
template <class T> struct move_is_nothrow : mpl::true_type {};
and have it defined whether there actually is a move constructor or not? Would that work? Or would it interact badly with copy-only types?
The latter. We can probably count on users not to write throwing move ctors, but we can't count on nonthrowing copy ctors. It needs to be conservative, i.e. something like: template <class T> struct has_nothrow_move : mpl::or_< has_nothrow_copy<T> // handles all builtins , has_move_constructor<T> // handle UDTs > {}; template <class T> struct has_move_constructor // Must assume UDTs don't have a move ctor : mpl::false_ {}; template <class T> struct has_nothrow_copy // Must assume UDTs have a copy ctor : has_trivial_copy<T> {}; otherwise, pair<movable_type, type_with_throwing_copy_and_no_move_ctor> has a throwing move constructor. -- Dave Abrahams BoostPro Computing http://www.boostpro.com