Re: [boost] [local] Review

Subject: Re: [boost] [local] Review
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2011-11-18 15:02:01

On 11/18/2011 01:27 PM, Jeffrey Lee Hellrung, Jr. wrote:
> 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.

Yes, the last "not" was accidental.

> [...]
>
>> 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.

I see. But why do you need local blocks to achieve that?

> - Jeff