Boost logo

Boost :

From: Eric Niebler (eric_at_[hidden])
Date: 2008-04-10 00:53:38

shunsuke wrote:
> 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".

I don't buy that argument, because to return a tuple, you need to state
the return type. If you say the return type is:

   tuple<int const &>

or even:

   result_of<make_tuple(int const &)>::type

... and you return a tuple containing a reference to a local variable,
you get what you asked for: a lot of pain. That's no worse than
declaring a function to return an "int const &" and returning a
reference to a local.

It's not even a problem with the new function declarator syntax in C++0x:

   auto foo() -> decltype(make_tuple(???))

This can't be made to return a reference to a local variable because no
local variables are in scope.

> 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.

I think your argument is specious.

> FWIW, I usually prefer compatibility. :-)

I honestly don't know what the right answer is. I'd like more people to
weigh in.

Eric Niebler
Boost Consulting

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