Subject: Re: [boost] [reference_wrapper] add operator()(Args...) to reference_wrapper
From: Philipp Moeller (philipp.moeller_at_[hidden])
Date: 2012-05-10 05:32:53
"Jeffrey Lee Hellrung, Jr." <jeffrey.hellrung_at_[hidden]> writes:
> On Wed, May 9, 2012 at 3:04 AM, Philipp Moeller <
> philipp.moeller_at_[hidden]> wrote:
>> "Jeffrey Lee Hellrung, Jr." <jeffrey.hellrung_at_[hidden]> writes:
>> > On Fri, Apr 20, 2012 at 5:03 AM, Philipp Moeller <
>> > philipp.moeller_at_[hidden]> wrote:
>> >> Given that Boost now has perfect forwarding emulation through Boost.Move
>> >> and a better result_of, would it be possible to enable reference_wrapper
>> >> to forward the function call operator?
>> >> The current behavior is somewhat surprising and makes a few of the most
>> >> promising applications of reference_wrapper (reference wrap polymorphic
>> >> boost::function objects) impossible with code that is no prepared to
>> >> work with reference_wrapper. It would also be more consistent with
>> >> reference_wrapper of the stdlib.
>> >> I can file a corresponding bug report and add a patch, if there is
>> >> interest.
>> > I think this would make a nice addition to the boost::reference_wrapper
>> > interface.
>> > Isn't there a CRTP base class in Boost that aids in programming
>> > nearly-perfect forwarding in C++03?
>> I couldn't find it and did it with PP.
>> I've added this as ticket #6876  for boost::bind. I'm unsure if this
>> belongs there or to some other component and the maintainer of bind
>> seems inactive. So I would be glad if someone else could have a look at
>> that patch, it might need some tweaking (especially the macro names).
>>  https://svn.boost.org/trac/boost/ticket/6876
> I think this is what I was thinking of:
As far as I see this does not use or enable move semantics and has a
higher compilation time. But I would surely prefer it over the current
solution if those features could be added. Maybe it should also include
a fully functional version if the necessary compiler features are
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk