Subject: Re: [boost] Rave for proposed Boost.Local (functions)
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2011-02-06 14:25:30
On 05/02/2011 14:47, Thomas Heller wrote:
> 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.
As I said, it does. With Boost.Local, you can still call polymorphic
functions on the variables captured from scope without specifying the
types of the arguments.