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

Subject: Re: [boost] [move] new rvalue reference emulation
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2012-01-26 18:18:56

On Thu, Jan 26, 2012 at 9:40 AM, Dan Ivy <danivy.mail_at_[hidden]> wrote:

> Sorry for taking so long to respond, I'm a little short in time
> lately. Unfortunately, I didn't get to this yet, so I'm just going to
> describe more-or-less where it's standing and, in particaular, what
> the outstanding issues are, so people could bring up comments or
> suggestions.
>
[...]

This is all pretty interesting, and much different from the solution I have
in mind. I, too, haven't had a convenient block of time to hash out a full
example, but it's on my TODO list :/

> Besides implictly catching rvalues, hiding the functions behind a
> macro solves another safety issue with "raw" BOOST_RV_REFs (which at
> the very least should be mentioned in the documentation, I don't think
> it currently is). BOOST_RV_REF parameters "maintain their rvalue-ness"
> in the context of the function. For example:
>
> void danger(const X&);
> void danger(BOOST_RV_REF(X));
>
> void naive(BOOST_RV_REF(X) x)
> {
>    danger(x);
> }
>
> Will call the rv-ref overload on emulation mode, where it should
> really call the lvalue one. This is dangerous, and it doesn't happen
> with the macro-ed functions.
>

I *thought* this had been mentioned somewhere, but I must be misremembering
because a quick glance through the documentation didn't yield any hits :/ I
agree that it should probably be listed among the other limitations.

- Jeff