On Thu, Jan 26, 2012 at 9:40 AM, Dan Ivy <danivy.mail@gmail.com> 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