Re: [boost] [move] new rvalue reference emulation

Subject: Re: [boost] [move] new rvalue reference emulation
From: Dave Abrahams (dave_at_[hidden])
Date: 2011-04-04 18:33:29

At Mon, 4 Apr 2011 10:36:29 -0700,
Jeffrey Lee Hellrung, Jr. wrote:
> 
> I've recently discovered (well, probably rediscovered) 

Whoa; this is cool, and I don't believe I've seen anything like it
anywhere before.

> an alternate rvalue
> reference emulation, one which allows rvalues ***of any arbitrary
> (move-emulation-enabled) type*** to be captured in C++03 and identified as
> rvalues, rather than references-to-const (there is a drawback, though, which
> I'll get to below; as usual, there's no "free lunch").  

I'm actually not sure there's no free lunch...

> Instead of using rv<T>& to capture arbitrary rvalues, I'll use a
> kind of type-erased emulated rvalue reference, generic_rv<...> (for

I think you should spell out "..." as "F, Result" in any descriptions
or it just gets confusing.  "Is he talking about variadic templates,"
I wondered?

> lack of a better name at the moment), which will just store a void
> pointer to the original, pre-type-erased object.  Of course, we need
> some way to recover the object back from the void pointer, and
> that's what the "..." template parameters are for.  This is where
> the (unfortunate) runtime overhead comes in, as some dispatching
> mechanism (e.g., function pointers) needs to be used to effect the
> recovery of the original, pre-type-erased object.  

First, did you try this with function references instead of function
pointers?

Next, which compilers did you try this on?

I've found that when everything is inlined and flow analysis allows
the compiler to "see" the source of function pointers/references, many
compilers can turn an indirect call into a direct one.

> The important
> difference between rv<T> and generic_rv<...> is that there's no T in
> the template parameter list "..." of generic_rv; more to the point,
> its template parameters are not deduced within the context of
> binding function arguments of some_fn, hence the compiler will be
> allowed to look for conversions from arbitrary rvalues to
> generic_rv<...>.  Hopefully that gives enough of an introduction to
> the idea.  Further details are probably best left to a code snippet.
> 
> Comments?  Specifically, should this be considered as an addition to
> Boost.Move's current emulation framework?  

Yes!

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com