Subject: Re: [boost] Rave for proposed Boost.Local (functions)
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2011-02-05 08:47:57
Mathias Gaunard <mathias.gaunard <at> ens-lyon.org> writes:
<snip>
> >> The problem with declaring those things at namespace scope is that they
> >> necessarily become far away from the lambda function you want to write.
> >
> > Arguing like that disqualifies every library, since the defintion of the
> > functions you want to use is _very_ far away... I don't see a point in that
> > argument.
>
> The argument I made in my initial message was the following: the problem
> with Phoenix is that it requires you to write boilerplate forwarding
> code for every function and class you want to be able to use.
>
> Then someone said something like "but that macro boilerplate is the same
> thing that you do with Boost.Local": no it's not, since it can only
> happen at namespace scope, which changes everything; and if I do that, I
> might as well use Boost.Local directly to define the lambda.
The BOOST_LOCAL_FUNCTION generates a struct in the current scope that can be
used as a functor.
That functor can be used with a phoenix::function object, since it is a model
of the Callable concept. So it really is the same thing. Of course, you use a
lot of features that you might have with defining the implementation of a
phoenix::function at namespace scope. However, Boost.Local doesn't give you
these possibilities in the first place.