Boost logo

Boost :

From: shunsuke (pstade.mb_at_[hidden])
Date: 2008-04-09 22:11:21

Eric Niebler wrote:
> Anyway, about the rvalue_wrapper<> Shunsuke proposed and I just
> endorsed. The issue is that today, users are writing code like this:
> int const i = 0;
> fusion::tuple<int> t = fusion::make_tuple(i);
> This is arguably wrong because it is storing an lvalue by value. This is
> probably more correct:
> int const i = 0;
> fusion::tuple<int const &> t = fusion::make_tuple(i);

It seems to depend on context or domain.
Proto may expect it, but

     int const i = 0;
     return fusion::make_tuple(i);

would be "ouch".
BTW, Egg offers "pack", which captures all the arguments by-reference.

> In C++0x, it will be very easy to get this more correct behavior. Will
> we change our functions (and function objects) then? Even if it breaks
> users' code?
> The alternative is to assume that T const & really means lvalue. And
> when you pass an rvalue you do it like this:
> fusion::tuple<int> t = fusion::make_tuple(rvalue(1));
> But then we have to live with this nightmare until C++0x arrives:
> // ouch!
> fusion::tuple<int const &> t = fusion::make_tuple(1);
> Yikes. Now I'm not sure. Safety or forward compatibility? Looks like we
> can't have them both.
> :-/

As shown above, lvalue/rvalue-ness doesn't guarantee the complete safety.
FWIW, I usually prefer compatibility. :-)


Shunsuke Sogame

Boost list run by bdawes at, gregod at, cpdaniel at, john at