Le 25/11/11 20:21, Mathias Gaunard a écrit :
On 11/25/2011 05:06 PM, Vicente Botet wrote:
That means that the interface of the local function is equivalent to the one we could write directly using a global function (I think that just don't needing to repeat the types is not a major advantage).
Of course it's equivalent, it's a macro.
The point is that
struct f_ { T0& a; T1& b; T2& c; T3& d;
f_(TO& a_, T1& b_, T2& c_, T3& d_) : a(a_), b(b_), c(c_), d(d_) { }
R operator()(A0 const& arg0, A1 const& arg1) const { return arg1 * a + arg2 / b + sin(c) * cos(d); } };
f_ f(a, b, c, d);
Is quite more verbose to write than
R BOOST_LOCAL_FUNCTION_PARAMS( bind a, bind b, bind c, bind d , A0 const& arg0, A1 const& arg1 ) { return arg1 * a + arg2 / b + sin(c) * cos(d); } BOOST_LOCAL_FUNCTION_NAME(f)
I was comparing it to R f(TO& a, T1& b, T2& c, T3& d, A0 const& arg0, A1 const& arg1) { return arg1 * a + arg2 / b + sin(c) * cos(d); } //... R r = f(a,b,c,d,a0,a1);
This macro automates the tedious forwarding of the context to a functor. It is, to me, its main use.
Forwarding the context could be only useful if the function is called several times, so the context is passed only once.
With Phoenix, I would write it as
// these two macros must be at file scope BOOST_PHOENIX_ADAPT_FUNCTION(R, sin_, sin, 1) BOOST_PHOENIX_ADAPT_FUNCTION(R, cos_, cos, 1)
BOOST_AUTO(f, arg1 * a + arg2 / b + sin_(c) * cos_(d));
The Phoenix version comes with many disadvantages however that have already been covered, and it's not that much better at terseness and macro-less-ness than Boost.Local.
I'm not seen this as an alternative to Boost.Local, as the goal is to been able to write the action using c++ statements. So the comparison is not fair.
I think it is apparent however that the BOOST_LOCAL_* macros are quite practical in comparison to the manually-written functor at the top.
I don't know if you have seen the example provided by Joel. If not please take a look. Best, Vicente