Re: [boost] [Boost.Local] Review

Subject: Re: [boost] [Boost.Local] Review
From: Lorenzo Caminiti (lorcaminiti_at_[hidden])
Date: 2011-11-23 06:06:27

On Wed, Nov 23, 2011 at 5:06 AM, Joel Falcou <joel.falcou_at_[hidden]> wrote:
> Le 19/11/2011 01:18, Lorenzo Caminiti a écrit :
>>
>> However, there are many other Boost libraries that use a macro API to
>> save the application writes from writing boiler-plate code
>
> Most of them are there to emulate a now C++11 facility or even better
> actually pushed for the same C+11 facility.

Can you be more specific? Which macros are to emulate C++11 facilities
and which ones are not? For example, ScopeExit is not (macro are not
to emulate a C++11 facility, they are just for boiler-plate).

>> With respect to other libraries, there is no other Boost library (and
>> no other library in general at least that I know of) that allows you
>> to write local functions while retaining statement syntax for the
>> function definition.
>
> The problem is that there is no need for C++ local function IMHO.

OK, that goes to the core of the issue IMO. Others have expressed a
different opinion in their reviews but I understand and respect your
opinion.

>> It is true that if you have C++11 lambdas you will probably use those
>> over Boost.Local closures. However, if you need to write code that
>> works on both C++11 and C++03 and performs like C++11 lambdas on
>> C++11, Boost.Local helps you there.
>
> C++03 is C++03, could be good for everybody if the C++11 bandwagon was
> jumped on by more people. Havign boost starting to provide C++11 based
> library could be the bootstrap C++11 require. Bootstrap that will ensure
> compiler vendors care about the new standard.

IMO it's a matter of time. Some tool chains (in my personal case GCC
based) need to be certified by 3rd parties (suppliers, etc) before
they can be used in some production code. It just takes time for every
supplier involved in the process to deal with the latest rev pushed
out by the compiler vendor. At the end of that process is the
application developer that finally gets the "ok, you can now use gcc
with C++11 on". That is just my own experience, others might have
different degrees of freedom in their ability to adopt their latest
compiler rev.

I'm putting the following into context:
>> c) A very personal reason: code written based on the proposed library for me
>> tends to be an unreadable mess. I have problems to remember, what arguments
>> to the macros means what, when to use additional parenthesis and when not,
>> etc. This is especially true when it comes to using 'default' and 'bind' in
>> the argument list. This just does not 'look right' to me.
>
> I put a lot of effort in making the macro syntax as natural as
> possible based on many comments from Boosters. Do you really find this
> code hard to follow? If so why?
>
>> int max = 0;
>> bool BOOST_LOCAL_FUNCTION_PARAMS(int x, const bind max) { // (1)
>>     return x<  a;
>> } BOOST_LOCAL_FUNCTION_NAME(small)
>> small(10);
>
> just using phoenix and/or lambda :
>
> int max = 0;
> auto small = _1 < max; // (2)

Or even better:

int max = 0;
auto small = [max](int x) { return x < max; } // (3)

IMO (and others have second this point), (3) is better than (2)
because at some point (3+ years from now?) everyone will be
comfortable with C++11 lambda syntax (3) because it's part of the
standard while there will still be people on your team that will have
no idea what you meant in writing (2). By the same token, the syntax
of (1) (statement syntax for the body) can be considered better than
the one of (2) even if (1) is more verbose and than (2) (verbosity
which might be a plus in the context to make the syntax more clear--
in fact (3) is more verbose than (2) but it is the new standard). All
of that said, if the a syntax is more or less understandable is a
subjective matter so I recognize that you and/or Hartmut feel
differently on this topic.

> local functions could be nice fi you have huge ones. One liners becomes
> nightmares and if you have a huge local function, make it a function.

IMO, we should leave these trade-offs to our library users: They can
decide to write 1-liners with (2), longer functions still locally with
(1), move out the function to non-local scope, or something else. Why
wouldn't we entrust our library users to be able to make the best
decision given that they will be ones directly facing the problem they
are trying to solve? Why wouldn't we provide tools/libraries to allow
them to chose in between these different options?

Thanks for your comments,
--Lorenzo