reference_wrapper() and operator()()
Dear reference wrapper authors, Is there any good reason that boost::reference_wrapper() does not provide a forwarding operator()(), so that we may use it to pass function objects by reference to algorithms? best regards -Thorsten
On Oct 30, 2007, at 6:22 PM, Thorsten Ottosen wrote:
Is there any good reason that boost::reference_wrapper() does not provide a forwarding operator()(), so that we may use it to pass function objects by reference to algorithms?
The only reason is laziness. I hacked up a partial implementation in the sandbox, but I never finished it. - Doug
Doug Gregor skrev:
On Oct 30, 2007, at 6:22 PM, Thorsten Ottosen wrote:
Is there any good reason that boost::reference_wrapper() does not provide a forwarding operator()(), so that we may use it to pass function objects by reference to algorithms?
The only reason is laziness. I hacked up a partial implementation in the sandbox, but I never finished it.
Are you using the preprocessor to generate the overloads? One could probably manually provide up to four arguments ... I assume this is more than enough, since the main use-case would be when passing a function object to an algorithm, in which case the mojaority of cases would be 1 or 2 arguments. -Thorsten
Thorsten Ottosen:
Doug Gregor skrev:
On Oct 30, 2007, at 6:22 PM, Thorsten Ottosen wrote:
Is there any good reason that boost::reference_wrapper() does not provide a forwarding operator()(), so that we may use it to pass function objects by reference to algorithms?
The only reason is laziness. I hacked up a partial implementation in the sandbox, but I never finished it.
Are you using the preprocessor to generate the overloads?
One could probably manually provide up to four arguments ... I assume this is more than enough, since the main use-case would be when passing a function object to an algorithm, in which case the mojaority of cases would be 1 or 2 arguments.
reference_wrapper::operator() needs result_of, and result_of would likely introduce a dependency into Boost.Bind on the PP library, the MPL, type traits, and everything underneath. The change may be worth it even at this cost, but it's not a no-brainer. It might be nicer if we could devise a way to deliver this functionality in a cost-free manner though, perhaps only in tr1::reference_wrapper?
Peter Dimov skrev:
Thorsten Ottosen:
Doug Gregor skrev:
Is there any good reason that boost::reference_wrapper() does not provide a forwarding operator()(), so that we may use it to pass function objects by reference to algorithms? The only reason is laziness. I hacked up a partial implementation in
On Oct 30, 2007, at 6:22 PM, Thorsten Ottosen wrote: the sandbox, but I never finished it. Are you using the preprocessor to generate the overloads?
One could probably manually provide up to four arguments ... I assume this is more than enough, since the main use-case would be when passing a function object to an algorithm, in which case the mojaority of cases would be 1 or 2 arguments.
reference_wrapper::operator() needs result_of, and result_of would likely introduce a dependency into Boost.Bind on the PP library, the MPL, type traits, and everything underneath. The change may be worth it even at this cost, but it's not a no-brainer. It might be nicer if we could devise a way to deliver this functionality in a cost-free manner though, perhaps only in tr1::reference_wrapper?
Oh, totally forgot about this. That sucks. I would be satisfied with a function template< class Return, class T > boost::function_obj_ref( const T& ); used like algo( first, last, boost::function_obj_ref<bool>( my_heavy_object ) ); -Thorsten
Thorsten Ottosen: ...
I would be satisfied with a function
template< class Return, class T > boost::function_obj_ref( const T& );
used like
algo( first, last, boost::function_obj_ref<bool>( my_heavy_object ) );
boost::bind<bool>( ref( my_heavy_object ), _1, _2, ... ) can be used for that, and so can function<bool(...)>( ref(my_heavy_object) ). This is partially why we don't feel much pressure to add operator() to reference_wrapper. The syntax is more burdensome though.
Peter Dimov wrote:
reference_wrapper::operator() needs result_of, and result_of would likely introduce a dependency into Boost.Bind on the PP library, the MPL, type traits, and everything underneath. The change may be worth it even at this cost, but it's not a no-brainer. It might be nicer if we could devise a way to deliver this functionality in a cost-free manner though, perhaps only in tr1::reference_wrapper?
One 'cheap' solution might be to enable it for compilers implementing C++0x features. For instance, decltype and variadic templates would appear to solve most the dependency dependency and PP problems - although I'm not sure what is involved in adding support for unary_function/binary_function dependency for one and two argument functions. -- AlisdairM
On Tue, 2007-11-06 at 13:41 +0000, AlisdairM wrote:
Peter Dimov wrote:
reference_wrapper::operator() needs result_of, and result_of would likely introduce a dependency into Boost.Bind on the PP library, the MPL, type traits, and everything underneath. The change may be worth it even at this cost, but it's not a no-brainer. It might be nicer if we could devise a way to deliver this functionality in a cost-free manner though, perhaps only in tr1::reference_wrapper?
One 'cheap' solution might be to enable it for compilers implementing C++0x features.
For instance, decltype and variadic templates would appear to solve most the dependency dependency and PP problems
Life will be better with 0x: template<typename... Args> auto operator()(Args&&... args) const -> decltype(get()(std::forward<Args>(args)...) { return get()(forward<Args>(args)...); } Doesn't solve the unary_function/binary_function issue you brought up, but it's a lot simpler than the C++98 version :) - Doug
participants (5)
-
AlisdairM -
Doug Gregor -
Douglas Gregor
-
Peter Dimov -
Thorsten Ottosen