[reference_wrapper] add operator()(Args...) to reference_wrapper
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. Cheers, Philipp Moeller
On Fri, Apr 20, 2012 at 5:03 AM, Philipp Moeller < philipp.moeller@geometryfactory.com> 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? - Jeff
"Jeffrey Lee Hellrung, Jr." <jeffrey.hellrung@gmail.com> writes:
On Fri, Apr 20, 2012 at 5:03 AM, Philipp Moeller < philipp.moeller@geometryfactory.com> 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 [1] 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). Footnotes: [1] https://svn.boost.org/trac/boost/ticket/6876 Cheers, Philipp Moeller
On Wed, May 9, 2012 at 3:04 AM, Philipp Moeller < philipp.moeller@geometryfactory.com> wrote:
"Jeffrey Lee Hellrung, Jr." <jeffrey.hellrung@gmail.com> writes:
On Fri, Apr 20, 2012 at 5:03 AM, Philipp Moeller < philipp.moeller@geometryfactory.com> 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 [1] 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).
Footnotes: [1] https://svn.boost.org/trac/boost/ticket/6876
I think this is what I was thinking of: http://www.boost.org/doc/libs/1_49_0/libs/functional/forward/doc/html/index.... - Jeff
"Jeffrey Lee Hellrung, Jr." <jeffrey.hellrung@gmail.com> writes:
On Wed, May 9, 2012 at 3:04 AM, Philipp Moeller < philipp.moeller@geometryfactory.com> wrote:
"Jeffrey Lee Hellrung, Jr." <jeffrey.hellrung@gmail.com> writes:
On Fri, Apr 20, 2012 at 5:03 AM, Philipp Moeller < philipp.moeller@geometryfactory.com> 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 [1] 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).
Footnotes: [1] https://svn.boost.org/trac/boost/ticket/6876
I think this is what I was thinking of:
http://www.boost.org/doc/libs/1_49_0/libs/functional/forward/doc/html/index....
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 available. Cheers, Philipp Moeller
On Thu, May 10, 2012 at 2:32 AM, Philipp Moeller < philipp.moeller@geometryfactory.com> wrote:
"Jeffrey Lee Hellrung, Jr." <jeffrey.hellrung@gmail.com> writes:
On Wed, May 9, 2012 at 3:04 AM, Philipp Moeller < philipp.moeller@geometryfactory.com> wrote:
"Jeffrey Lee Hellrung, Jr." <jeffrey.hellrung@gmail.com> writes:
On Fri, Apr 20, 2012 at 5:03 AM, Philipp Moeller < philipp.moeller@geometryfactory.com> 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 [1] 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).
Footnotes: [1] https://svn.boost.org/trac/boost/ticket/6876
I think this is what I was thinking of:
http://www.boost.org/doc/libs/1_49_0/libs/functional/forward/doc/html/index....
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 available.
Actually, looking at this a second time, this isn't the CRTP base class I was thinking of :/ This is mildly annoying that I can't find it... In any case, yes, if the appropriate compiler features are present (variadic templates and/or rvalue references), any solution should make use of those. - Jeff
participants (2)
-
Jeffrey Lee Hellrung, Jr. -
Philipp Moeller