Re: [boost] [local] Any "active Boost library author" in favor of Boost.Local?

Subject: Re: [boost] [local] Any "active Boost library author" in favor of Boost.Local?
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2011-11-25 14:21:37

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.