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

Subject: Re: [boost] New libraries implementing C++11 features in C++03
From: Gregory Crosswhite (gcrosswhite_at_[hidden])
Date: 2011-11-22 23:22:25

On Nov 23, 2011, at 12:21 PM, Joel de Guzman wrote:

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

Sure, there are cases where it works quite well.  Nobody here has been arguing that Boost.Lambda and friends are never the best solution for any problem.  As I have said before, although I don't like using Boost.Lambda for non-trivial things I frequently use it for trivial functions like the ones in your example above precisely because it is so concise.

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

But that very link is all about a proposal to build lambdas into the language as a "workaround" for the fact that the current C++ standard and compilers made library-based solutions have serious limitations such as undecipherable error messages!  That is, building lambdas into the C++ language so that plain C++ syntax could be used was *exactly* a "workaround the problem of C++ error messages".  To the extent that Boost.Lambda did indeed pave the way for the implementation of C++11 lambdas, it was by providing an example of how it *shouldn't* be done, namely by using a library based solution that employs non-standard C++ syntax for function bodies.

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

But the whole point of using a library is to make one's life easier!  Are you really saying that it is "backwards thinking" to avoid using a shiny new library merely because it is so difficult to use in practice that it makes one's life harder rather than easier?

> What we should do instead is to find better solutions, not hide the problems.

Sure, but until them some of us actually want to write code *now* that solve the problems that we currently face, rather than waiting first for C++ compiler technology to improve enough that a particular library will finally become useful for us to use to solve our problem.

Furthermore, for older releases of compilers there will *never* be solutions to many of these problems since their development has been frozen in favor of the newer releases.

> This is Boost!

If Boost really were primarily about providing functionality that will only become truly useful on compilers that don't actually exist yet, then I am not sure why anyone would pretend that Boost was *also* intended for practical every-day use by programmers just looking to solve problems.  I mean, your point that Boost should be pushing the envelope is well taken, but surely this shouldn't be done at the expense of refusing to ever address the issues that we face in the present.

As a wise man once said:  "As you know, you go to code with the compilers you have, not the compilers you might want or wish to have at a later time."

Cheers,
Greg