Re: [boost] [Bind] How do I get bind to deduce the return type of for_each?
On Mon, Apr 19, 2010 at 1:04 PM, Thomas Jordan <thomasjordan_at_[hidden]> wrote:
Thomas Jordan wrote:
[snip] I was hoping I could accomplish the objective of passing an algorithm into an algorithm jgenerically, just doing everything at point of call using just
Boost.bind, the std::algorithms (wrapped) and using if necessary some boost.function functors to help type deduction. Are we saying this isn't possible?
----------------------------------------- Roland Bock replied:
************************************
<snip> Â for_each(vov.begin(), vov.end(), Â Â Â Â bind(for_each< vocType::iterator, function<void (myClass&)> >, Â Â Â Â Â Â bind<vocType::iterator>(&vocType::begin, _1), Â Â Â Â Â Â bind<vocType::iterator>(&vocType::end, _1), Â Â Â Â Â Â protect(bind(&myClass::func, _1)) Â Â Â Â Â Â ) Â Â Â Â ); } // -----------------------------------------------------------
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. 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? Best regards, Tom.
On Wed, Apr 21, 2010 at 1:17 AM, Thomas Jordan <thomasjordan@btinternet.com> 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@btinternet.com> 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>
On Wed, Apr 21, 2010 at 5:32 PM, OvermindDL1 <overminddl1@gmail.com> wrote:
#include <boost/spirit/include/phoenix2.hpp>
My mistake, for Boost.Phoenix 2 it is just: #include <boost/spirit/include/phoenix.hpp> And the docs are here: http://www.boost.org/doc/libs/release/libs/spirit/phoenix/
participants (2)
-
OvermindDL1 -
Thomas Jordan