Re: [boost] Rave for proposed Boost.Local (functions)

Subject: Re: [boost] Rave for proposed Boost.Local (functions)
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2011-02-05 08:08:53

On 05/02/2011 12:40, Thomas Heller wrote:
> Mathias Gaunard<mathias.gaunard<at>  ens-lyon.org>  writes:
>> On 03/02/2011 16:45, Thomas Heller wrote:
>>
>>>>> Now, let's consider another case, I want to do a.foo(b.bar()) + c.baz,
>>>>> but with a, b, and c taken from the scope, and I don't want to have to
>>>>> specify the types of a, b, and c. I can't do that in Phoenix without
>>>>> defining the foo, bar and baz functions at namespace scope, since they
>>>>> must have a template operator(), which is only allowed at that level. I
>>>>> can, however, do that with no problem with Boost.Local.
>>>>
>>>> Well, you have seen nothing yet
>>>
>>>
> http://svn.boost.org/svn/boost/sandbox/SOC/2010/phoenix3/libs/phoenix/doc/html/
> phoenix/inside/extending_actors.html
>>> A boilerplate macro for that would be a very welcome contribution...
>>
>> All of this still needs to happen at namespace scope.
>
> Sure it would. The point of this exercise was to adapt some "old style" C++
> class to be used in a phoenix expression. Much in the fashion of
> BOOST_FUSION_ADAPT_STRUCT. Since you complained about using member functions
> in a phoenix expression is a pain ...
>
>> 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.