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

From: David Abrahams (dave_at_[hidden])
Date: 2008-07-01 14:16:45

Eric Niebler wrote:

-- snip 2^10 overloads --

Yeah, that's probably too much, but I'm not sure we have to support
forwarding for that many arguments.  The only thing rvalue forwarding
buys you (and it can be a big win) is the ability for the wrapped thing
to make certain optimizations.  It's a good idea when you can do it.  If
you can't do it, you can fall back to lvalues and in C++03 you've still
done a credible job.

> David Abrahams wrote:
>> 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.

I'm a little confused.

Proper rvalue detection for *wrapper functions* or not, we have no way
of writing make_vector so that it stores all rvalues and references
lvalues.  So in C++03, that function needs some hints about when to
store values.  I'm not convinced it doesn't need those hints in C++0x.
After all, any time you build a vector of references from lvalues, those
references (or copies thereof) can be made to dangle.

That doesn't mean a wrapper function should not forward non-const
rvalues to its wrapee.

>>> It wouldn't be useful for
>>> my purposes. What I took from the discussion about result_of and C++03
>>> was that, for a function object that cares about lvalue/rvalue-ness to
>>> work consistently across C++03 and C++0x, assuming rvalue-ness and
>>> opting in for lvalue-ness with reference_wrapper<> is really the only
>>> option. But if you have an insight, I'd be happy to reopen that
>>> discussion. It was rather unsatisfying last time.
>>
>> I just think that since you don't have permission to mutate a const
>> rvalue anyway, forwarding it as a const reference doesn't really hurt
>> anyone.
> 
> When I've gotten it wrong, it hurts.

Maybe you're making assumptions that you really can't afford to make
(that storing a reference to an lvalue, even when properly detected, is
a good idea).

>>> If we give up on backwards compatibility, a merger is still possible. I
>>> think Joel's suggestion is workable. I like the approach he and Hartmut
>>> are using in the Spirit 2 transition.
>>
>> Sounds like he changed his mind after all.
> 
> He did?

I saw a message to Jaakko go by that I interpreted that way.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com