Thanks for the review, Thomas! I just have a couple comments. On Fri, Nov 18, 2011 at 10:49 AM, Thomas Heller <thom.heller@googlemail.com>wrote: [...]
Let me first start with some general comments. I personally find the decision to support two syntaxes not a good path to follow. While I understand the rationale behind it, and the desire to have the variadic macro version, having both might become a maintenance nightmare. Also, reading through the documentation, most of the time is spent on explaining, the difference between the two syntaxes. Why not just stick with one and concentrate on the functionality? Additionally, despite the introductory motivating statement ("Local functions are a form of information hiding and are useful for dividing procedural tasks into subtasks which are only meaningful locally, avoiding cluttering other parts of the program with functions, variables, etc unrelated to those parts.") I can not see that this library solves this appropriately. I personally think that exposing macros as the interface to program with the library does not lead to a nice and clean design of ones code. Boost.Local is very different from other heavily macro based libraries like Boost.Parameter. It is different, because I would consider Boost.Local not as a infrastructure library but as a library for end users. This being said, i would not like to see application code cluttered with overly verbose calls to macros. As boost is trying to not only push the boundaries of C++ it should also try to set examples of best C++ practice. I would not consider Macro calls to interface with a library not good practice.
Ummm...was the double negative in the last sentence intentional? I'm guessing you only meant to include one or the other "not", not both. [...]
Local Blocks: I can't see the value in that one. The example in the documentation doesn't help either, as those things are easily detected by any modern compiler, with the appropriate warning levels (ok, not in the assert case, but for other boolean contexts at least gcc does).
I *believe* there has been an instance in my own code where I had to const_cast a range to coerce a range algorithm to use const_iterator's for efficiency reasons...or something like that. I don't remember the details of the situation, but I can imagine instances where const access to an object would be more efficient than mutable access, e.g., if mutable access via operator[] must return a proxy. It can be difficult to guarantee in general that the compiler would optimize a syntactically-mutable-semantically-const access into the equivalent syntactically-const access. - Jeff