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 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