Re: [boost] [range/iterators/algorithms/phoenix/bind...] Coordinated Approach

From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2008-07-01 13:44:11

On Tue, Jul 1, 2008 at 6:57 PM, Eric Niebler <eric_at_[hidden]> wrote:
> David Abrahams wrote:
>>
>> Eric Niebler wrote:
>>>
>>> David Abrahams wrote:
>>>>
>>>> I don't suppose it's possible to forward lvalues and
>>>> const rvalues as lvalues, and mutable rvalues as rvalues?  I haven't
>>>> thought of a way, but that would be as close to "perfect" as we might
>>>> expect to get in C++0x and it would be close enough for me :-)
>>>
>>> We would need 2^N overloads,
>>
>> That's OK for small N
>
> boost::function and phoenix have argument limits of 10 by default. 2^10 is a
> big number. Can't wait for variadics and rvalue refs.
>

I use a wrapper that does perfect forwarding up to 5 arguments (and
all ref/all const ref for the remaining 10). I never needed more than
that and I do not think it has an important contribution to compile
time (that is, heavy lambda usage will kill compile time way more than
that).

>>> and it would be unsound because it would
>>> incorrectly forward const rvalues as lvalues.
>>
>> Can you show me an example of a "sound" function that treats a const
>> rvalue differently from an lvalue, please?
>
> fusion::make_vector(), for instance. It returns a fusion::vector<> where the
> members can be held by value or by reference. Getting it wrong can lead to
> dangling references. Proto has similar function objects that need to be
> careful about the lifetime of temporaries.

IMHO you can ever safely hold on a parameter by reference unless you
somehow explicitly decorate that parameter (with reference_wrapper for
example). I do not see how brute force forwarding or C++0x perfect
forwarding change anything. I should probably read again the thread
referenced by David Abrahams

-- 
gpd