Re: [Boost-users] [Bind] Understanding protect

28 Mar 2012

      On Wed, Mar 28, 2012 at 11:13 AM, Thomas Heller
wrote:
...
On 03/28/2012 11:45 AM, Robert Jones wrote:
...
On Wed, Mar 28, 2012 at 10:04 AM, Thomas Heller
**wrote:
On 03/28/2012 09:47 AM, Robert Jones wrote:
...
On Tue, Mar 27, 2012 at 8:24 PM, Thomas Heller
...
****wrote:
You might also want to consider phoenix::lambda, it is like protect,
but
...
slightly more powerful.
your example would then read:
#include
int main( )
{
    std::vector<int>   v;
    v += 0,1,2,3,4,5,6;
    using boost::phoenix::bind;
    using boost::phoenix::lambda;
    using boost::phoenix::placeholders::******_1;
    using boost::phoenix::local_names::_******1;
for_each( v.begin( ), v.end( ),
        bind(g, lambda(_a = _1)[bind(f, _a)]));
return 0;
}
Please don't remind me! I'd love to, but I'm stuck in the antediluvian
days
of 1.37!
- Rob.
Ouch. In that case, protect should work just fine.
Here is a complete and working example:
https://gist.github.com/****2224915 https://gist.github.com/**2224915<
https://gist.github.**com/2224915 https://gist.github.com/2224915>
Hi Tom
Thanks for the time you've spent on this- much appreciated.
I can see where you're going with this approach, however if I've
understood
it correctly it
sidesteps the hard bit in that the function g() now takes a unary callable
and a value. My key
constraint here is that g() MUST take a nullary callable object, and hence
the bind machinations
MUST produce a fully bound, unevaluated, nullary callable object.
I feel like I'm banging-on a bit here - sorry!
Ha, no problem, I enjoy solving such problems :)
After jumping through all kinds of different hoops, I updated the gist:
https://gist.github.com/**2224918 https://gist.github.com/2224918
I hope this fits your usecase better :) The original function is
unchanged, I just added the trampoline to rebind the bound functor. Well,
not the most elegant solution, but might work.
Now that's a solution!
So, looking to generalise and clean-up a bit,...
* is there a compelling reason why invoke declares a local variable, rather
than invoking g directly?
* would it be reasonable to pass g as a ctor parameter to g_trampoline?
* could g_trampoline reasonably be templated on return type (currently
void)?

This seems to me to be a pretty common use-case, possibly also for two and
three argument versions
of f(). Is there a general facility here that's worth formalising? Maybe
that's already been subsumed by
your phoenix work? Just thinking out-loud.

Thx, Rob.
variable