On Fri, Nov 18, 2011 at 6:41 PM, Hartmut Kaiser <hartmut.kaiser@gmail.com> 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