Re: [boost] New libraries implementing C++11 features in C++03

Subject: Re: [boost] New libraries implementing C++11 features in C++03
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2011-11-22 15:32:06

On Tue, Nov 22, 2011 at 11:39 AM, Vicente J. Botet Escriba <
vicente.botet_at_[hidden]> wrote:

> Le 22/11/11 18:27, Jeffrey Lee Hellrung, Jr. a écrit :
>
>> Within the discussion for the review of the proposed Boost.Local library,
>> Hartmut Kaiser raised a concern that I think should be addressed more
>> broadly by the community, if possible.  I quote Hartmut:
>>
>>  Ok. However this raises a more serious question. Should we as the
>>> Boost community still encourage solutions and libraries solely for
>>> portability with ancient compilers? I'd say no, but YMMV. Boost will
>>> be still around 2, 5, or 10 years from now. What's the utility of
>>> adding such a _solely_ backwards oriented library from this POV?
>>>
>> Indeed, I ask the community, do such libraries belong in Boost?  If so, is
>> the bar for acceptance of such libraries automatically and necessarily
>> higher than libraries that introduce genuinely new capabilities in C++11?
>> If so, what additional criteria must such a library meet?
>>
>>
>>  Hi,
>
> 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); }));
> 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
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,
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.

- Jeff