Boost logo

Boost :

Subject: Re: [boost] [Bind] How do I get bind to deduce the return type of for_each?
From: Thomas Jordan (thomasjordan_at_[hidden])
Date: 2010-04-21 03:17:19


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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk