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

Subject: Re: [boost] New libraries implementing C++11 features in C++03
From: Joel de Guzman (joel_at_[hidden])
Date: 2011-11-22 21:21:50

On 11/23/2011 3:39 AM, Vicente J. Botet Escriba 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.

As Hartmut said, Boost.Move is an infrastructure library needed by Boost itself.
Move semantics is crucial. Local functions are not.

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

Local cannot be an approximation of lambda. As mentioned again and again,
a good approximation of lambda is already existing in Boost. Namely: bind,
lambda and phoenix. I posted a Spirit example of lambda in action using
Phoenix:

  http://tinyurl.com/7w2h2r9

Try as hard as you can, but you cannot ever come close to the clarity of
the syntax presented there. Proponents of locals have cited error-messages
generated by the compiler as a justification for Locals. Locals is probably
a good workaround. But hear me out...

Keep in mind that Boost has been at the forefront of C++ library development.
It is because of these libraries that push the limits of C++ that we see the
advancement in C++ that we enjoy now in C++11. Case in point is Boost Lambda
authored by Jaakko Jaarvi (et.al.) which ushered in C++11 lambda:

  http://tinyurl.com/7um5yr4

If we chose to workaround the problem of C++ error messages in 2002, we would
have ended up with something like Locals and there will be no experience that
will pave the way towards C++11 lambda.

Instead of working around the problems and offer less than elegant APIs
and libraries for the sake of portability with ancient compilers, what
we should do is push the C++ compiler writers to give us library writers
more power to address the problems such as the often cited deluge of
undecipherable error messages. TMP libraries are ubiquitous in modern C++.
Avoiding them because of the problem of error messages is backwards thinking.
What we should do instead is to find better solutions, not hide the problems.

This is Boost!

Regards,
-- 
Joel de Guzman
http://www.boostpro.com
http://boost-spirit.com