On 5/14/2010 4:32 AM, Ion Gaztañaga wrote:
On 12/05/2010 22:08, Jeffrey Lee Hellrung, Jr. wrote:
I don't think, as implemented, is_movable works for non-class types (at least that used to be the case, and I think the only change in the implementation has been the introduction of a boost::mpl::bool_). I think for non-class types T, at least in c++03, is_movable<T> should evaluate to false without causing a compiler error.
Well, it shouldn't cause any error, is_convertible should lead to false:
//This works in MSVC 7.1 bool mv = ::boost::is_movable<int>::value;
Hmmm...yes, you're right. I seem to remember that, at some point, it looked like is_movable was trying to instantiate rv< int > (and hence complained about deriving from int), but I don't have the context anymore... :/
I don't recall seeing anything concerning has_nothrow_move other than a short description about how it defaults to false and could hurt performance if not specialized. Can you explain the intended use for has_nothrow_move? Is this related to N2983 [1]? Speaking of which, do you have any idea what the status of throwing move constructors is as far as the c++ committee is concerned, whether you agree with the resolution provided by N2983, and if so, have you thought about providing move_if_noexcept (or something similar)?
Since this has been a moving target until now, I haven't seriously thought about emulating those proposals, but I do expect to work on them in the future, when they are completely definitive. Regarding performance gains with has_nothrow_move, you can optimize away some exception rollback actions in container internals if you know that moving objets will not throw. And to use some advanced memory allocation strategies, like forward buffer expansion, you need this nothrow guarantees because some containers, like vector, require strong exception guarantees for some operations (like push_back).
Right, I understand the optimization considerations. I'm torn whether has_nothrow_move is appropriate to include at this juncture. About all I can say is that it *currently* lacks sufficient explanation in the documentation as to its purpose. As you said, throwing move constructors has been a "moving target". I'm hoping someone with more familiarity on the subject can step in and advise.
If has_nothrow_move turns out to be widely used, it may be a good idea to package the "no-throw-ness" of the move constructor within a move emulation enabling macro (ENABLE_NOTHROW_MOVABLE), e.g., by defining a typedef that has_nothrow_move can detect, or maybe a boolean static constant within the class indicating whether the move constructor throws, so that you can make the "no-throw" property conditional on the "no-throw-ness" of member objects. In any case, one step at a time...
The good part of template specializations is that you don't need to instantiate the class to check if the class has that property, and this is important specially when defining recursive data types like recursive containers:
class recursive { vector<recursive> leafs; };
Yes, I agree, it is certainly convenient to be able to use has_nothrow_move<T> even if T is incomplete. I still don't like the idea of forcing users to specialize has_nothrow_move when it seems like the *common* case is non-throwing move constructors...hmmmm...
As far as the utility of is_movable in c++0x, it looks like it's only used in uninitialized_move and uninitialized_copy_or_move. This doesn't seem like enough justification to provide it for c++0x, since uninitialized_{copy_or_}move *could* be implemented without it just fine. Furthermore, is_movable will only be true in c++0x if a movable type has a nested typedef boost_move_emulation_t, which seems to exclude, e.g., STL data structures. I would think a simpler course of action would be to relegate is_movable to strictly c++03...
Yes, that might be an option. I do use it in containers for some sfinae tricks, but I think it's only for C++03 code. It seems that in C++0x it's not easy to know if a class really has a rvalue reference overload constructor (or at least, it wasn't some time ago, maybe things have changed in recent proposals-drafts), so it might be possible to limit it to C++03.
I think that would be prudent. - Jeff