Boost logo

Boost :

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>> 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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at