Re: [boost] Case study: Boost.Local versus Boost.Phoenix

Subject: Re: [boost] Case study: Boost.Local versus Boost.Phoenix
From: Edward Diener (eldiener_at_[hidden])
Date: 2011-02-06 08:24:58

On 2/5/2011 4:04 PM, Lorenzo Caminiti wrote:
> On Fri, Feb 4, 2011 at 10:55 AM, Mathias Gaunard
> <mathias.gaunard_at_[hidden]>  wrote:
>> On 04/02/2011 13:35, Artyom wrote:
>>
>>> I'm sorry is it only me or it would be much more readable
>>> and maintainable to write:
>>>
>>> namespace {
>>>     struct my_lambda  {
>>>         foo_type&foo;
>>>         bar_type&bar
>>>         my_lambda(foo_type&local_foo,bar_type&local_bar) :
>>>             foo(local_foo),
>>>             bar(local_bar)
>>>         {
>>>         }
>>>
>>>         void operator()(a_type a) const
>>>         {
>>>               /// Your body goes there
>>>         }
>>>
>>>     };
>>> }
>>>
>>> void my_function()
>>> {
>>>      foo_type foo;
>>>      bar_type bar;
>>>
>>>      my_lambda lambda(foo,bar);
>>>      for_each(as.begin(),as.end(),lambda);
>>>      // or something else
>>> }
>>
>> That's exactly the kind of thing Boost.Local does, it generates that
>> structure but avoids you the boilerplate of declaring foo and bar members
>> and forwarding them in the constructor. Also, it uses Boost.Typeof, so you
>> don't have to write their type.
>>
>> Also, it is much more valuable to declare this as
>>
>> void my_function()
>> {
>>     foo_type foo;
>>     bar_type bar;
>>
>>     struct
>>     {
>>        foo_type&foo;
>>        bar_type&bar
>>        my_lambda(foo_type&local_foo,bar_type&local_bar) :
>>            foo(local_foo),
>>            bar(local_bar)
>>        {
>>        }
>>
>>        void operator()(a_type a) const
>>        {
>>              /// Your body goes there
>>        }
>>
>>     } lambda(foo, bar);
>>     for_each(as.begin(),as.end(),lambda);
>>     // or something else
>> }
>>
>> since the lambda is right next to where it is used (which is the whole point
>> of the exercise).
>>
>> It is true however that the syntax of the Boost.Local macro could greatly be
>> simplified.
>>
>> I think
>>
>> LOCAL_FUNCTION(R, f, (a, b, c)(T0 a0, T1 a1), body)
>>
>> is a better syntax. (a, b, c) would catch a, b, and c in the scope and would
>> be optional.
>>
>> (Of course, it requires the use of the C99 preprocessor)
>
> Sorry, C++ preprocessor only -- that was a requirement for me... (Can
> you imagine how much the syntax can be simplified with varidiac
> macros... I can!! Too bad I can't use them...).

For the purposes of Boost compatibility you can use variadic macros as 
long as BOOST_NO_VARIADIC_MACROS is not defined.

You can also use my variadic_macro_data library in the sandbox to 
interoperate variadic macros with Boost PP and to simplify some Boost PP 
regarding tuples when variadic macros is supported.

So you might be able to offer a clearer syntax for your macros for those 
compilers which do support variadic macros ( there are quite a few of 
them ) if you wanted to do so, even though it does not fit your own 
needs. But this is of course totally up to you.

The downside to variadic macros, which Boost PP data types do not share, 
is that variadic macro notation can only be used as the last parameter 
of any given macro.