On 11/19/2011 11:44 AM, Lorenzo Caminiti wrote:
On Fri, Nov 18, 2011 at 10:19 PM, Joel de Guzman <joel@boost-consulting.com> wrote:
On 11/19/2011 6:44 AM, Lorenzo Caminiti wrote:
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. I understand. I disagree but I understand your point. I disagree because the use of macros in this context saves the user from writing verbose boiler-plate code.
IMO, it is similar to Boost.ScopeExit: Instead of providing the SCOPE_EXIT macros we could have said that the user writes the code to bind the variables deducing their types and it programs the local class with the exit code in the desstructor all of that by hand. However, using macros saves the user to write all of that and as I user I personally appreciate that. It is true that there is a trade off between the readability cost of using macros and the benefit of not having to write boiler-plate code. I find that trade off acceptable for libraries like Boost.SopeExit or even ForEach and (of course ;) ) also for my library so I don't have to write the boiler-plate code for the binding and the casting to pass the local class as a template parameter.
I share Thomas' sentiment. But IMO, it's really not about using macros. it's about the syntax. Boost.Foreach looks exactly like a for loop. The proposed boost locals syntax is arcane. IMO, bottomline: it's about the design of the DSEL regardless how it is implemented. And, the syntax proposed is, well, utterly ugly. Anything more complex than foreach, done using the PP will be a mess. An ugly syntax can be acceptable
That is fine but the definition of "ugly" is subjective so IMO it should be left up to the reviewers (and Thomas' point is clear, the syntax is ugly for him as one of the reviewers).
IFF there is no other way to do it. In this case (locals), there are better ways of doing the same thing.
But there is no other way to do locals allowing to use statement syntax for the function definition.
Why can't we C++ programmers just accept the fact that we don't have *true* local functions like those in Pascal and Modula? Challenge: try to port one moderately sized Pascal code (I suggest a recursive descent calculator parser) using your proposed library. I know the result will be utterly ugly and unreadable compared to the real thing, but let the readers be the judge. I can write the same using non-local functions and/or offline function objects using only straight C++. The result will be very readable. Not as elegant as the one using Modula's local functions, but certainly better than using your proposed locals library. That is what I mean by "better ways of doing the same thing". Again, I share Thomas' sentiment. It's not worth the additional complexity and arcane syntax. There are two scenarios here: 1) simple local functions --for those, you don't want the complexity of using a macro DSEL, just use plain functions and function objects. 2) Moderate to complex programs --for those, the macro syntax will get in the way of clarity of code -- for those, just use plain functions and function objects. And I am not even mentioning c++ lambda. You can nitpick all you want, but it's still nitpicking. Nitpicks are not valid rationale for justifying a library for boost. Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com