[boost] [local] implementation using C++11 lambdas

Subject: [boost] [local] implementation using C++11 lambdas
From: Lorenzo Caminiti (lorcaminiti_at_[hidden])
Date: 2011-11-22 17:55:50

On Tue, Nov 22, 2011 at 3:32 PM, Jeffrey Lee Hellrung, Jr.
<jeffrey.hellrung_at_[hidden]> wrote:
> On Tue, Nov 22, 2011 at 11:39 AM, Vicente J. Botet Escriba <
>> I think that there is a difference between Boost.Local and Boost.Move.
>> Boost.Move provides an emulation of a C++11 feature on compilers that don't
>> provides this feature.
>>
>> Boost.Local provides an emulation of a feature that has not been accepted
>> to c++11.
>> Note that I'm not saying that Boost.Local should not be accepted, but I'm
>> sure that things will be different if Boost.Local provided an emulation for
>> c++11 lambdas, that is, if in c++11 compilers the macros could be able to
>> generate C++11 lambdas.
>>
>
> Well, named lambdas are basically the same as local functions, no?  What I
> really mean is, Local provides an imperfect emulation of C++11 lambdas, but
> by the same token, Boost.Move provides an imperfect emulation of rvalue
> references.
>
> The question I have for the Boosters that don't like the local function
>> approach is if they will accept as a good approximation of the following
>> use of a lambda expression
>>
>> std::sort(x, x + N, [](float a, float b) {return std::abs(a) <
>> std::abs(b); });
>>
>> the storage on a temporary as in
>>
>> auto cmp = [](float a, float b) {return std::abs(a) < std::abs(b); };
>> std::sort(x, x + N, cmp);
>>
>> If Lorenzo would be able to define a macro that could be used to replace
>> the named lambda as in
>>
>> BOOST_AUTO_LAMBDA(cmp, float a, float b, bool, ({return std::abs(a) <
>> std::abs(b); }));

Yes, this should be trivial but what would be its value? Note that on
C++11 compilers the existing Boost.Local local function implementation
has compile and run time performance comparable to the ones of C++11
lambdas:
https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_local/Alternatives.html#boost_local.Alternatives.local_function_benchmarking

Therefore, why would you care if the local function is internally
implemented using a C++11 lambda (macro above) or a local struct
(macro below) given that there's no significant performance impact?

bool BOOST_LOCAL_FUNCTION(float a, float b) {
    return std::abs(a) < std::abs(b);
} BOOST_LOCAL_FUNCTIONS_END(cmp)

(Also this has better error messages because the body is out of the
macros so the compiler line numbers retain their usual meaning.)

In summary, the current Boost.Local implementation already performs as
well as C++11 lambdas on C++11 compilers and it also works on C++03
compilers. Therefore the current Boost.Local implementation already
allows you to portably program named lambdas (but not lambdas because
local functions cannot be defined within expressions) at no
performance cost with respect to C++11 lambdas.

>> std::sort(x, x + N, cmp);
>>
>> could you consider that this is promoting good usage of C++11 features on
>> compilers that don't provide them and be a good candidate for a Boost
>> library?
>>
>
> This is drifting away from my intended thread topic a little bit.  But,
> nonetheless...  Isn't this latter syntax trivial to implement with the
> present macros provided by Local?  And, as an aside, the significant

Yes, it should be trivial.

> disadvantage to the above versus splitting the declaration over 2 macro
> instantiations is that compiler error messages from the body of the
> function would be less informative (essentially missing line numbers).  Oh,

Yes, all compiler errors would have the same line number
(significantly) reducing their informative value.

> and I don't know if you can reliably do your BOOST_AUTO_LAMBDA syntax
> without variadic macros.  That said...it may be convenient to provide
> something like that the BOOST_AUTO_LAMBDA macro for simple and small named
> lambdas with no unparenthesized commas.

HTH,
--Lorenzo