Re: [boost] [Boost.Local] Review

Subject: Re: [boost] [Boost.Local] Review
From: Lorenzo Caminiti (lorcaminiti_at_[hidden])
Date: 2011-11-18 19:18:14

On Fri, Nov 18, 2011 at 6:41 PM, Hartmut Kaiser
<hartmut.kaiser_at_[hidden]> wrote:
> This is not a full review, mainly because I have not had the time to devote
> more than a quick glance over the documentation (which is a good read, btw).

Hello Hartmut, thank you very much for your comments. I hope you will
have the time to submit a full review (especially now that the end
date has been extended) because some of the comments you make are more
about general programming styles and macro usage than about specific
aspects of Boost.Local.

> Upfront my vote: no, please do not include this library into Boost.
>
> My reasons are:
>
> a) Boost is a library which has quite some visibility not only for library
> writers but also for application developers. IMHO, Boost not only has the
> task of finding new ways for using C++, but it plays the role of
> evangelizing good programming style, great API design, and thoughtful
> functionality. Using macros as the sole API of a library to be mainly used
> by application writers (not library authors) is not a good idea because of

However, there are many other Boost libraries that use a macro API to
save the application writes from writing boiler-plate code
(Boost.ScopeExit, Boost.ForEach, ... I am sure the list is longer
maybe someone can reply with the complete list here). Why should we
threat Boost.Local differently in this respect?

> all those well know problems related to macros: difficult to debug, error
> messages are even more difficult to interpret than those generated by TMP,

Boost.Local macros are comparable in debug and error message
complexity to the macros used by Boost.ScopeExit. In this case, the
macros are only used in the function declaration so the
compiler-errors fully support you as usual in correcting your function
definition code (which is where most of the complexity of the function
is).

I personally find Boost.ScopeExit macros as well as Boost.Local macros
easy to use. Did you have issues in using either one of these macros?

> macros are type agnostic and have absolutely no knowledge of C++, etc.

Why is this "type agnostic" and "absolutely no knowledge of C++" a
problem for Boost.Local? Can you provide an example so I can
understand your point better?

> b) The proposed library does not add any functionality which couldn't be
> _easily_ replaced by using existing C++ language features or libraries. This

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.

> is especially true if we talk about C++11 (which we should, IHMO).

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) 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) {
    return x < a;
} BOOST_LOCAL_FUNCTION_NAME(small)
small(10);

Of course, I am asking for you honest and unbiased opinion :)

(If default is really such a big deal then I can just avoid providing
default parameters for local functions. But honestly I don't think
that having a syntax you get used to within ~1week for an optional
feature like default local function parameters is really the point, is
it?)

Thank you very much for your comments and I hope you will have more
time to write a full review of Boost.Local.
--Lorenzo