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

Subject: Re: [boost] New libraries implementing C++11 features in C++03
From: Lorenzo Caminiti (lorcaminiti_at_[hidden])
Date: 2011-11-23 04:53:33

On Tue, Nov 22, 2011 at 9:21 PM, Joel de Guzman
<joel_at_[hidden]> wrote:
> 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...

Nope, not just a good workaround for error-messages. Proponents of
Locals mentioned two (2) main things as advantages. Please let's cite
both of them correctly:
1) Use statement syntax for function definition.
2) Compiler error retain their usual meaning for the function definition.
While these two things are related from an library implementation
prospective, they are two different advantages for the library
end-user.

The politically correct sentence fro the docs: "[Local functions] can
be defined using C++ statement syntax plus eventual compiler errors
follow the usual format of C++ statement errors".
https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_local/Alternatives.html#boost_local.Alternatives.local_functions

> 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

"less than elegant API" is a subjective statement. I could argue that
Lambda and Phoenix offer a "less" than elegant API because it differs
from C++ statement and now C++11 lambda expression syntax.

> and libraries for the sake of portability with ancient compilers, what

C++03 are not _ancient_ at my work, they are current and they will be
for the next 2 years (optimistic), or 5 years (pessimistic)-- I think
3 years is realistic in my case. Others have expressed the same
situation. On the contrary C++11 are futuristic compilers at this
moment at my work. I understand that at other's work place the
situation might be different.

> 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!

How is a library like Boost.Algorithm pushing the limit? It's a very
useful library, I want its algorithms for my C++03 work (even if a lot
of these algorithms are in the C++11 STL) so I voted for admission of
Boost.Algorithm. I still stand for that "yes" vote because I need to
use its algorithms even if trivial (e.g., all_of) on C++03.

IMO, Boost.Algorithm is not pushing the limit at all but it makes my
programming experience easier. Why shouldn't Boost be about marking
programming easier even if it doesn't push the limit? I think it
should. Actually I think that making programming easier for the
library end users should the Boost main goal (no need to push the
limit unless necessary to offer the user a feature that will make
their programming experience easier). Otherwise, Boost is a library to
show off research projects that push the limit instead of a library
that provides good (best?) solutions to be used in production code.

HTH,
--Lorenzo