Re: [boost] [Bind] How do I get bind to deduce the return type of for_each?

Subject: Re: [boost] [Bind] How do I get bind to deduce the return type of for_each?
From: OvermindDL1 (overminddl1_at_[hidden])
Date: 2010-04-21 19:32:59

On Wed, Apr 21, 2010 at 1:17 AM, Thomas Jordan
<thomasjordan_at_[hidden]> wrote:
> OvermindDL1 responded:
>
> You should use Boost.Phoenix, it can do what Bind and Lambda and
> others can, plus more, including the above with no issues.
>
> _____________________________________
>
> Thanks for the suggestion. I will take a look at Phoenix. I have been drawn to Boost::bind because it is small, self-contained, relatively easy to understand and surprise-free.
>
> I like the extra power of Lambda - it is beautiful for relatively simple operator expressions and function bindings, however, when I tried to do anything more complex, e.g., multiple Lambda sub-expressions separated by commas, it started to go wrong for me. Â I found it difficult to predict what would happen, esp. with regard argument binding, order of evaluation, side-effects, etc. Â Even when I saw the result, I wasn't sure how it had got there. This could just be due to my lack of experience, holes in the documentation, or even compiler issue. Â Also, the syntax what is bit prickly.
>
> I am not trying to start a 'which is best Boost functional library' thread, but such issues, if present, would (sadly) steer me away from Phoenix too. I just couldn't recommend it to your average C++ programmer at my workplace.

Boost.Phoenix does not have any of the afore-mentioned problems, and
it has plenty of things for handling scope as well, you can create
Boost.Phoenix functors inside of Boost.Phoenix functors inside of
Boost.Phoenix etc... and so forth, all handling scope properly,
something Boost.Lambda is not capable of.

On Wed, Apr 21, 2010 at 1:17 AM, Thomas Jordan
<thomasjordan_at_[hidden]> wrote:
> Also, I got the impression Boost::bind is in TR1, therefore is likely to be in the next standard, whereas Lambda expressions would be best handled by core-language extensions (also mooted for the standard)?
>
> Finally, if Boost::Phoenix is so good (I don't doubt it that it is), why is is buried away under another library, and are there any plans to consolidate/deprecate any/all of these libraries?

Boost.Phoenix 2 may be under the Spirit umbrella currently, but it is
fully functional, fully capable.  Boost.Phoenix 3 has been accepted as
a full Boost citizen, it is just going to be a rewrite of
Boost.Phoenix 2 using Boost.Proto, there is no reason not to use
Boost.Phoenix 2 as-is.  I think the global include (although once you
have things made, it is better to include the individual pieces for
compiling speed reason) is:
  #include <boost/spirit/include/phoenix2.hpp>