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) This macro automates the tedious forwarding of the context to a functor. It is, to me, its main use. 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 think it is apparent however that the BOOST_LOCAL_* macros are quite practical in comparison to the manually-written functor at the top.