Re: [boost] [local] Review

Subject: Re: [boost] [local] Review
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2011-11-18 14:27:09

Thanks for the review, Thomas!  I just have a couple comments.

On Fri, Nov 18, 2011 at 10:49 AM, Thomas Heller
<thom.heller_at_[hidden]>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