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

Subject: Re: [Boost-users] [Bind] Understanding protect
From: Robert Jones (robertgbjones_at_[hidden])
Date: 2012-03-28 06:41:34

On Wed, Mar 28, 2012 at 11:13 AM, Thomas Heller
<thom.heller_at_[hidden]>wrote:

> On 03/28/2012 11:45 AM, Robert Jones wrote:
>
>> On Wed, Mar 28, 2012 at 10:04 AM, Thomas Heller
>> <thom.heller_at_[hidden]>**wrote:
>>
>>  On 03/28/2012 09:47 AM, Robert Jones wrote:
>>>
>>>  On Tue, Mar 27, 2012 at 8:24 PM, Thomas Heller
>>>> <thom.heller_at_[hidden]>****wrote:
>>>>
>>>>
>>>>  You might also want to consider phoenix::lambda, it is like protect,
>>>> but
>>>>
>>>>> slightly more powerful.
>>>>> your example would then read:
>>>>> #include<boost/phoenix.hpp>
>>>>>
>>>>> 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