boost::transform_iterator and boost::lambda functors
Is there a way to make a boost::lambda functor adaptable, that is to make it define result_type? There is a ret<> function template that lets one specify the result type, but the returned functor still does not have result_type typedef. I've encountered the problem trying to use boost::transform_iterator with a boost::lambda functor: std::vector<int> intVect; boost::make_transform_iterator(intVect.begin(), boost::lambda::_1 / 2); transform_iterator<> does not compile comlaining the functor does not have result_type. As a workaround I had to write something like: template<class R, class T> struct result_type_wrapper : T { typedef R result_type; result_type_wrapper(T const& t) : T(t) {} }; template<class R, class T> inline result_type_wrapper<R, T> result_type(T const& t) { return t; } boost::make_transform_iterator(intVect.begin(), result_type<int>(boost::lambda::_1 / 2)); Am I missing something? Is there a way to avoid using result_type_wrapper<>? -- Maxim Yegorushkin
"Maxim Yegorushkin" <e-maxim@yandex.ru> writes:
Is there a way to make a boost::lambda functor adaptable, that is to make it define result_type? There is a ret<> function template that lets one specify the result type, but the returned functor still does not have result_type typedef.
I've encountered the problem trying to use boost::transform_iterator with a boost::lambda functor:
std::vector<int> intVect; boost::make_transform_iterator(intVect.begin(), boost::lambda::_1 / 2);
transform_iterator<> does not compile comlaining the functor does not have result_type.
As a workaround I had to write something like:
template<class R, class T> struct result_type_wrapper : T { typedef R result_type; result_type_wrapper(T const& t) : T(t) {} };
template<class R, class T> inline result_type_wrapper<R, T> result_type(T const& t) { return t; }
boost::make_transform_iterator(intVect.begin(), result_type<int>(boost::lambda::_1 / 2));
Am I missing something? Is there a way to avoid using result_type_wrapper<>?
You could use boost::make_adaptable from boost/bind/make_adaptable.hpp, but there really ought to be a version of make_transform_iterator that does that for you. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> wrote:
Am I missing something? Is there a way to avoid using result_type_wrapper<>?
You could use boost::make_adaptable from boost/bind/make_adaptable.hpp, but there really ought to be a version of make_transform_iterator that does that for you.
Shame on me. I knew about boost/bind/make_adaptable.hpp but I thought it could only be used with a bind functor and did not give it a try. I wonder, why doesn't boost::lambda::ret<> privide that functionality of boost::make_adaptable<>? It would certainly made sense and saved me and hopefully other people from troubles. -- Maxim Yegorushkin
"Maxim Yegorushkin" <e-maxim@yandex.ru> writes:
David Abrahams <dave@boost-consulting.com> wrote:
Am I missing something? Is there a way to avoid using result_type_wrapper<>? You could use boost::make_adaptable from boost/bind/make_adaptable.hpp, but there really ought to be a version of make_transform_iterator that does that for you.
Shame on me. I knew about boost/bind/make_adaptable.hpp but I thought it could only be used with a bind functor and did not give it a try.
I wonder, why doesn't boost::lambda::ret<> privide that functionality of boost::make_adaptable<>? It would certainly made sense and saved me and hopefully other people from troubles.
It can't. The result type of the lambda expression depends on its inputs. result_type is only one type. Adaptable functions are fundamentally non-polymorphic. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
On Thu, Jun 10, 2004 at 03:47:40PM -0400, David Abrahams wrote:
"Maxim Yegorushkin" <e-maxim@yandex.ru> writes:
David Abrahams <dave@boost-consulting.com> wrote:
Am I missing something? Is there a way to avoid using result_type_wrapper<>? You could use boost::make_adaptable from boost/bind/make_adaptable.hpp, but there really ought to be a version of make_transform_iterator that does that for you.
Shame on me. I knew about boost/bind/make_adaptable.hpp but I thought it could only be used with a bind functor and did not give it a try.
I wonder, why doesn't boost::lambda::ret<> privide that functionality of boost::make_adaptable<>? It would certainly made sense and saved me and hopefully other people from troubles.
It can't. The result type of the lambda expression depends on its inputs. result_type is only one type. Adaptable functions are fundamentally non-polymorphic.
Maxim is talking about ret<>, which has a monomorphic type: http://www.boost.org/libs/lambda/doc/ar01s05.html#sect:overriding_deduced_re... I think it would be both possible and valuable for ret<T> and bind<T> to define result_type. -- -Brian McNamara (lorgon@cc.gatech.edu)
David Abrahams wrote:
"Maxim Yegorushkin" <e-maxim@yandex.ru> writes:
David Abrahams <dave@boost-consulting.com> wrote:
I wonder, why doesn't boost::lambda::ret<> privide that functionality of boost::make_adaptable<>? It would certainly made sense and saved me and hopefully other people from troubles.
It can't. The result type of the lambda expression depends on its inputs. result_type is only one type. Adaptable functions are fundamentally non-polymorphic.
The result type of ret<R>(expr) is always R. That's what it does. That's _all_ it does. ;-) http://www.boost.org/libs/lambda/doc/ar01s05.html#sect:overriding_deduced_re... The result type of bind<R>(...) is also R, and the TR1 bind requires a ::result_type in this case, but lambda doesn't conform yet.
"Peter Dimov" <pdimov@mmltd.net> writes:
David Abrahams wrote:
"Maxim Yegorushkin" <e-maxim@yandex.ru> writes:
David Abrahams <dave@boost-consulting.com> wrote:
I wonder, why doesn't boost::lambda::ret<> privide that functionality of boost::make_adaptable<>? It would certainly made sense and saved me and hopefully other people from troubles.
It can't. The result type of the lambda expression depends on its inputs. result_type is only one type. Adaptable functions are fundamentally non-polymorphic.
The result type of ret<R>(expr) is always R. That's what it does. That's _all_ it does. ;-)
Sorry, I thought it was something else. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
participants (4)
-
Brian McNamara -
David Abrahams -
Maxim Yegorushkin -
Peter Dimov