bind's bind vs lambda's bind
I see two "bind" adapters in Boost 1.32: one from bind and one from lambda. Although they seem to have the same interface, each seems to have its own implementation. In effect, "using namespace boost; using namespace boost::lambda;" doesn't work. What's the story here? Are they going to merge someday? Is one a full superset of the other, or better implemented (and I should stick to that one)? Do you have suggestions about handling this? TIA... -- Jean-Louis Leroy Sound Object Logic http://www.soundobjectlogic.com
Hello Jean-Louis Leroy, The things even worse, there is a third bind version in boost, the one from phoenix library. It's a real headache to choose between them. Maybe it is worth to benchmark somehow all these binds? J> I see two "bind" adapters in Boost 1.32: one from bind and one from J> lambda. Although they seem to have the same interface, each seems to J> have its own implementation. J> J> In effect, "using namespace boost; using namespace boost::lambda;" J> doesn't work. What's the story here? Are they going to merge someday? J> Is one a full superset of the other, or better implemented (and I J> should stick to that one)? Do you have suggestions about handling J> this? J> J> TIA... J> -- Vyacheslav E. Andrejev System Architect, Excelsior, LLC
Vyacheslav E. Andrejev wrote:
Hello Jean-Louis Leroy,
The things even worse, there is a third bind version in boost, the one from phoenix library. It's a real headache to choose between them. Maybe it is worth to benchmark somehow all these binds?
FWIW, Phoenix will merge with Lambda, so consider that as one. Cheers, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
On 8/25/05, Joel de Guzman <joel@boost-consulting.com> wrote:
Vyacheslav E. Andrejev wrote:
Hello Jean-Louis Leroy,
The things even worse, there is a third bind version in boost, the one from phoenix library. It's a real headache to choose between them. Maybe it is worth to benchmark somehow all these binds?
FWIW, Phoenix will merge with Lambda, so consider that as one.
Cheers, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
OT - what's the likely time-scale for that - I've just started using Lambda in anger & written my first Spirit parser intended for production code, so I've gone through the ordeal of learning (bits of) Lambda and Phoenix in parallel - arg1 vs _1 - aaaargghhh - tripped over that one a few times :-) Stuart Dootson
Stuart Dootson wrote:
OT - what's the likely time-scale for that - I've just started using Lambda in anger & written my first Spirit parser intended for production code, so I've gone through the ordeal of learning (bits of) Lambda and Phoenix in parallel - arg1 vs _1 - aaaargghhh - tripped over that one a few times :-)
Sorry, can't give an estimate. However, Phoenix-2 should be out fairly soon. It's feature complete now. Apart from a couple of bits and pieces (e.g. tests, review, cleanup), it is in perfect shape (Thanks to those who helped: Dan Marsden and Daniel Wallin). Jaakko agreed that Phoenix-2 will be the basis of the merger. After the release of Phoenix-2, work the merger should proceed smoothly. Phoenix-2 has all the feature set of Lambda, plus a lot more. For example, you can now use _1 and arg1 interchangeably :-) Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Peter Dimov wrote:
Joel de Guzman wrote:
Phoenix-2 has all the feature set of Lambda, plus a lot more. For example, you can now use _1 and arg1 interchangeably :-)
I hope that you'll be able to use my_1 as well if you specialize is_placeholder. ;-)
Oh, consider that done. I'm also thinking of the best way to have your bind test suite run without having to rewrite them all for phoenix. Have you any thoughts? Cheers, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Joel de Guzman wrote:
Peter Dimov wrote:
Joel de Guzman wrote:
Phoenix-2 has all the feature set of Lambda, plus a lot more. For example, you can now use _1 and arg1 interchangeably :-)
I hope that you'll be able to use my_1 as well if you specialize is_placeholder. ;-)
Oh, consider that done. I'm also thinking of the best way to have your bind test suite run without having to rewrite them all for phoenix. Have you any thoughts?
We can play macro games... but it seems easier for you just to steal the tests and put them in the Phoenix test suite. If you are aiming at a real TR1 bind, you'll have to add (much) more coverage anyway; boost::bind is too simple.
David Abrahams wrote:
"Peter Dimov" <pdimov@mmltd.net> writes:
If you are aiming at a real TR1 bind, you'll have to add (much) more coverage anyway; boost::bind is too simple.
Really! Are you planning to remedy that?
I think that the current implementation of boost::bind does have its advantages. :-)
"Peter Dimov" <pdimov@mmltd.net> writes:
David Abrahams wrote:
"Peter Dimov" <pdimov@mmltd.net> writes:
If you are aiming at a real TR1 bind, you'll have to add (much) more coverage anyway; boost::bind is too simple.
Really! Are you planning to remedy that?
I think that the current implementation of boost::bind does have its advantages. :-)
I'm sorry, that's a little too cryptic for me. What advantages? If Boost.Bind isn't going to be TR1 compliant, what will John Maddock's Boost.TR1 use? -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
"Peter Dimov" <pdimov@mmltd.net> writes:
David Abrahams wrote:
"Peter Dimov" <pdimov@mmltd.net> writes:
If you are aiming at a real TR1 bind, you'll have to add (much) more coverage anyway; boost::bind is too simple.
Really! Are you planning to remedy that?
I think that the current implementation of boost::bind does have its advantages. :-)
I'm sorry, that's a little too cryptic for me.
What advantages?
A mostly green text matrix on a wide variety of compilers.
If Boost.Bind isn't going to be TR1 compliant, what will John Maddock's Boost.TR1 use?
Boost.Bind doesn't support return type deduction via result_of and custom bind expressions and placeholders via is_bind_expression and is_placeholder. It implements the "portable subset" of tr1::bind. A boost::bind expression should be a valid tr1::bind expression, so it's forward compatible.
"Peter Dimov" <pdimov@mmltd.net> writes:
David Abrahams wrote:
"Peter Dimov" <pdimov@mmltd.net> writes:
What advantages?
A mostly green text matrix on a wide variety of compilers.
If Boost.Bind isn't going to be TR1 compliant, what will John Maddock's Boost.TR1 use?
Boost.Bind doesn't support return type deduction via result_of and custom bind expressions and placeholders via is_bind_expression and is_placeholder. It implements the "portable subset" of tr1::bind. A boost::bind expression should be a valid tr1::bind expression, so it's forward compatible.
Thanks for explaining.. I guess we will want to try to make phoenix::bind usable independently from the rest of phoenix, then. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (1)
-
David Abrahams -
Jean-Louis Leroy
-
Joel de Guzman -
Peter Dimov -
Stuart Dootson -
Vyacheslav E. Andrejev