On Wed, Mar 28, 2012 at 11:13 AM, Thomas Heller <thom.heller@googlemail.com> wrote:
On 03/28/2012 11:45 AM, Robert Jones wrote:
On Wed, Mar 28, 2012 at 10:04 AM, Thomas Heller
<thom.heller@googlemail.com>wrote:

On 03/28/2012 09:47 AM, Robert Jones wrote:

On Tue, Mar 27, 2012 at 8:24 PM, Thomas Heller
<thom.heller@googlemail.com>**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>

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

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