Re: [boost] [Boost.Move] A few notes

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ó:
> 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