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
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk