[lambda] extension question
Hi, I'm trying to learn how to make my own lambda compatible function objects and I'm hoping that someone can nudge me in the right direction. My first try is called tuple_element. It takes an index as a template parameter and a tuple as an argument, returning the element at the given index: //should print "x" cout << tuple_element<1>(_1)(tuple<int,std::string>(2, "x")); I've got everything working except for the sig template. tuple_element looks like (mostly copied from lambda source code): template <int Index> struct tuple_element_action {}; template <int Index, typename Arg> inline const lambda_functor< lambda_functor_base< tuple_element_action<Index>, tuple<lambda_functor<Arg> > > > tuple_element(const lambda_functor<Arg>& a) { return lambda_functor_base< tuple_element_action<Index>, tuple<lambda_functor<Arg> > > ( tuple<lambda_functor<Arg> >(a)); } and the action: template<typename Args, int Index> class lambda_functor_base<tuple_element_action<Index>, Args> { public: Args args; template <class T> struct sig : tuples::element<Index,T> {}; explicit lambda_functor_base(const Args& a) : args(a) {} template<class RET, CALL_TEMPLATE_ARGS> RET call(CALL_FORMAL_ARGS) const { return detail::select(get<0>(args), CALL_ACTUAL_ARGS).get<Index>(); } }; When I try to compile my example in VC 7.1 I get an error that seems to indicate that the type being passed to the sig template is boost::tuples::null_type. Everything works if I hardwire it like: template <class T> struct sig { typedef std::string type; }; Any ideas? Thanks, Brock
On Jul 18, 2005, at 6:19 PM, Brock Peabody wrote:
When I try to compile my example in VC 7.1 I get an error that seems to indicate that the type being passed to the sig template is boost::tuples::null_type. Everything works if I hardwire it like:
template <class T> struct sig { typedef std::string type; };
Yes, a null_type is passed to sig. This is because the signature of the zero argument lambda function (in lambda_functor class) signature is instantiated always, regardless of whether it is called or not. And there the argument list is just null_type. Hence, the return type deduction is not allowed to cause a compilation error in the case where the argument tuple to sig is null_type. Best, Jaakko
Any ideas?
Thanks, Brock
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Jaakko Järvi, jarvi@cs.tamu.edu
Jaakko Järvi wrote:
On Jul 18, 2005, at 6:19 PM, Brock Peabody wrote:
When I try to compile my example in VC 7.1 I get an error that seems to indicate that the type being passed to the sig template is boost::tuples::null_type. Everything works if I hardwire it like:
template <class T> struct sig { typedef std::string type; };
Yes, a null_type is passed to sig. This is because the signature of the zero argument lambda function (in lambda_functor class) signature is instantiated always, regardless of whether it is called or not. And there the argument list is just null_type. Hence, the return type deduction is not allowed to cause a compilation error in the case where the argument tuple to sig is null_type.
FYI, this is a typical problem. Phoenix-2 has fixed this nagging problem. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
On Behalf Of Joel de Guzman
FYI, this is a typical problem. Phoenix-2 has fixed this nagging problem.
Is Phoenix-2 going to be in 1.33? I just read through the documentation I found at http://spirit.sourceforge.net/dl_more/phoenix-2.zip. It looks great!
Brock Peabody wrote:
On Behalf Of Joel de Guzman
FYI, this is a typical problem. Phoenix-2 has fixed this nagging problem.
Is Phoenix-2 going to be in 1.33? I just read through the documentation I found at http://spirit.sourceforge.net/dl_more/phoenix-2.zip. It looks great!
No. But better yet, Jaakko and I are collaborating and it will be the basis of the LL/Phoenix merger. This should happen very soon now as things are progressing very quickly thanks to some help from Daniel Wallin and Dan Marsden. Yeah, Phoenix-2 is pure rock and roll :-) The STL mapping, for example, is simply amazing. Esp. the "lazy" algorithms and the sequence intrinsics. <<BTW, if you want to check things out, get the latest from the Spirit CVS in the PHOENIX_V2 branch.>> Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
On Behalf Of Joel de Guzman
No. But better yet, Jaakko and I are collaborating and it will be the basis of the LL/Phoenix merger. This should happen very soon now as things are progressing very quickly thanks to some help from Daniel Wallin and Dan Marsden.
So will that be in 1.33? :)
Yeah, Phoenix-2 is pure rock and roll :-) The STL mapping, for example, is simply amazing. Esp. the "lazy" algorithms and the sequence intrinsics.
It seemed like it had all the goodies I was missing from FC++.
<<BTW, if you want to check things out, get the latest from the Spirit CVS in the PHOENIX_V2 branch.>>
Cool, thanks!
Brock Peabody wrote:
On Behalf Of Joel de Guzman
No. But better yet, Jaakko and I are collaborating and it will be the basis of the LL/Phoenix merger. This should happen very soon now as things are progressing very quickly thanks to some help from Daniel Wallin and Dan Marsden.
So will that be in 1.33? :)
I thought I answered that above? Sorry, no. It won't make it in 1.33. Maybe 1.34? Cheers, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Joel de Guzman Sent: Tuesday, July 19, 2005 3:29 PM To: boost@lists.boost.org Subject: Re: [boost] [lambda] extension question
Brock Peabody wrote:
On Behalf Of Joel de Guzman
No. But better yet, Jaakko and I are collaborating and it will be the basis of the LL/Phoenix merger. This should happen very soon now as things are progressing very quickly thanks to some help from Daniel Wallin and Dan Marsden.
So will that be in 1.33? :)
I thought I answered that above? Sorry, no. It won't make it in 1.33. Maybe 1.34?
Oops, I misread that as there won't be a Phoenix 2 (at all) because it's merging with LL. I'll check out what's in CVS in the meantime! Thanks Brock
It is rumored that Joel de Guzman uttered the following:
Jaakko and I are collaborating and it will be the basis of the LL/Phoenix merger. This should happen very soon now as things are progressing very quickly thanks to some help from Daniel Wallin and Dan Marsden.
This being the case, is there any point to any incremental work on BLL as it currently exists? I was talking with Gary Powell offline, and he'd said at some point there had been a desire to see BLL leverage more of MPL in its implementation, and I'd thought about taking some time to see if I could help in that direction. It doesn't make much sense, though, if P-2 is the Wave of the future. Christopher
Christopher Currie wrote:
It is rumored that Joel de Guzman uttered the following:
Jaakko and I are collaborating and it will be the basis of the LL/Phoenix merger. This should happen very soon now as things are progressing very quickly thanks to some help from Daniel Wallin and Dan Marsden.
This being the case, is there any point to any incremental work on BLL as it currently exists? I was talking with Gary Powell offline, and he'd said at some point there had been a desire to see BLL leverage more of MPL in its implementation, and I'd thought about taking some time to see if I could help in that direction. It doesn't make much sense, though, if P-2 is the Wave of the future.
Of course, Jaakko will have the final say on this. In any case, as far as Phoenix-2 is concerned, we're already very close to release as the remaining bits and pieces fall into place, thanks to Dan Marsden who did most of the final chores. Phoenix-2 already (heavily) leverages MPL and its half-runtime counterpart fusion. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Christopher Currie wrote:
It is rumored that Joel de Guzman uttered the following:
Jaakko and I are collaborating and it will be the basis of the LL/Phoenix merger. This should happen very soon now as things are progressing very quickly thanks to some help from Daniel Wallin and Dan Marsden.
This being the case, is there any point to any incremental work on BLL as it currently exists? I was talking with Gary Powell offline, and he'd said at some point there had been a desire to see BLL leverage more of MPL in its implementation, and I'd thought about taking some time to see if I could help in that direction. It doesn't make much sense,
Here's Jaakko's reply: On Sep 15, 2005, at 12:59 AM, Joel de Guzman wrote: though, if P-2 is the Wave of the future.
Of course, Jaakko will have the final say on this. In any case, as far as Phoenix-2 is concerned, we're already very close to release as the remaining bits and pieces fall into place, thanks to Dan Marsden who did most of the final chores. Phoenix-2 already (heavily) leverages MPL and its half-runtime counterpart fusion.
Phx/LL merger means that the current lambda code base will largely be replaced by new code in the Boost distribution. So no, I wouldn't spend too much time on cleaning the current code up. Best, Jaakko
Joel de Guzman wrote:
Jaakko Järvi wrote:
Yes, a null_type is passed to sig. This is because the signature of the zero argument lambda function (in lambda_functor class) signature is instantiated always, regardless of whether it is called or not. And there the argument list is just null_type. Hence, the return type deduction is not allowed to cause a compilation error in the case where the argument tuple to sig is null_type.
FYI, this is a typical problem. Phoenix-2 has fixed this nagging problem.
How?
Peter Dimov wrote:
Joel de Guzman wrote:
Jaakko Järvi wrote:
Yes, a null_type is passed to sig. This is because the signature of the zero argument lambda function (in lambda_functor class) signature is instantiated always, regardless of whether it is called or not. And there the argument list is just null_type. Hence, the return type deduction is not allowed to cause a compilation error in the case where the argument tuple to sig is null_type.
FYI, this is a typical problem. Phoenix-2 has fixed this nagging problem.
How?
By disabling the nullary operator() when appropriate (e.g. by computing the minimum arity). Cheers, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
On Behalf Of Jaakko Järvi:
Yes, a null_type is passed to sig. This is because the signature of the
zero argument lambda function (in lambda_functor class) signature is instantiated always, regardless of whether it is called or not. And there the argument list is just null_type. Hence, the return type deduction is not allowed to cause a compilation error in the case where the argument tuple to sig is null_type.
That makes sense. After looking around some more I found what seems to be an easier way to do it using the action<> template that hides this problem. Thanks, Brock
participants (5)
-
Brock Peabody -
Christopher Currie -
Jaakko Järvi -
Joel de Guzman -
Peter Dimov