On 8/25/05, Joel de Guzman 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

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. ;-)

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" 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. :-)

David Abrahams wrote:

"Peter Dimov" writes:

...

David Abrahams wrote:

...

"Peter Dimov" 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" writes:

David Abrahams wrote:

...

"Peter Dimov" 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