El 11/01/2012 18:29, Dan Ivy escribió:
Hi,
I was recently trying out Boost.Move and a few issues worth sharing surfaced:
Hi, sorry if my replies are not detailed enough, but lately I have no much time to read the mailing list and might have missed some points.
1. It would be helpful to have configuration macros to force emulation mode, even on C++11 compilers, as well as to disable move semantics altogether (that is, the conversion operators to boost::rv& should be disabled, and move/forward should return lvalue-references. BOOST_RV_REF and friends should remain intact, so that overloads remain unique.) In many cases, the higher level semantics of a program are expected to be identical under all three configurations, so having a quick way to switch between them is useful during testing/debugging.
Forcing emulation would be easy, if you think it's useful, please fill a ticket so that I can remember that for the new version. Disabling move semantics it's a bit extrange I don't think it should be added without a good reason.
2. Boost.Move is a little bit too opaque, as it stands. What's really missing are Boost.Move-aware type traits. Things like add_rvalue_reference are often necessary to calcuate return types of move-aware generic functions, and so on. Whether this belongs in Boost.TypeTraits or Boost.Move is a separate question. Likewise, there should be type traits to calculate the return types of boost::move and, in particular, boost::forward. On C++11, the return type of forward<T> conincides with add_rvalue_reference<T>, but not so in emulation mode, hence the necessity for this trait.
I agree. I added in trunk (and 1.49) some utilities (based on Jeffrey's code) in the detail namespace and started using them on some other libraries (intrusive, container): is_rvalue_reference add_rvalue_reference remove_rvalue_reference declval() They are experimental, any contribution/test/comment is welcome.
3. For some reason, the emulated boost::move is written so it doesn't accept temporaries. This doesn't play too nicely with forwarding:
The main use case I considered for BOOST_FWD_REF were constructors and emplace functions. I needed them extensively in Boost.Container so maybe I was biased.
4. There are many one-liner functions floating around that aren't declared inline. This is a big-deal for less-capable compilers, such as Sun and older versions of GCC. In fact, they simply won't inline boost::move calls without it.
Ok, thanks for the ticket.
5. boost::rv<T> unconditionally inherits from T, with the assumption that it would never get instanciated for non-class types, since it is only ever used as a reference. This is a false assumption in general. In the context of overload-resolution, the compiler is allowed, though not required, to instanciate the types of function parameters, even if the best overload can be determined without doing this. Consider this move-aware, but not very useful vector class:
Ok, thanks for the ticket. Ion