Subject: Re: [boost] [Boost.Move] A few notes
From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2012-01-12 17:27:13
El 11/01/2012 18:29, Dan Ivy escribió:
> I was recently trying out Boost.Move and a few issues worth sharing
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
> 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):
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk