On Fri, Nov 18, 2011 at 11:23 PM, Joel de Guzman <joel@boost-consulting.com> wrote:
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?
Because now we have Boost.Local so we can program true local functions with all their functionality :) (If not, which local function functionality is missing from Boost.Local?)
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.
Sure, after the review I'll program such an example and add it to the Examples section https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_loca... BTW, do you have some code (possibly Pascal) to start from? Do you have such a code programmed in Phoenix already?
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".
Well, we'll have to wait and see the code example to judge. Please note that had this request come ~1year ago when I started collecting feedback, I'd be happy to program the example just using the proposed library syntax even before starting to implementing it. Too bad no one thought about it back then... but it's never too late. To the end of exercising my library, I did program /all/ the examples I found from the references I looked at (N2511: https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_loca... https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_loca... Including the examples from GCC extension nested functions: http://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_loca... But these are short examples.
Again, I share Thomas' sentiment. It's not worth the additional complexity and arcane syntax. There are two scenarios here:
What do you mean by "complexity" here? As for the syntax, with respect the the normal C++ syntax: // some local scope int f(int x) { ... // lots of instructions here } It requires you to do two things: 1) Wrap the function name and parameter list in two macros. 2) And, move the function name after the function body. // some local scope int PARAMS(int x) { ... // lots of instructions here } NAME(f) To me and others this does not look arcane but I understand this is a subjective. BTW, why would you consider the above syntax arcane and the one below "nice"? (I am honestly asking such a question, it is not that people cannot change their minds, there would be no improvement otherwise, but if that is the case I would sincerely like to know what prompted such a change.) -- from: http://lists.boost.org/Archives/boost/2011/02/176638.php -- On Fri, Feb 4, 2011 at 5:43 PM, Joel de Guzman <joel@boost-consulting.com> wrote:
On 2/5/11 6:03 AM, Alexander Nasonov wrote:
As far is a am concerned, I still find this syntax overly verbose. I do realize though that this is just a toy example. For better comparison, Here is how the same thing would like in Boost.Phoenix:
Steven and I were playing with different syntaxes few years ago
We came up with something like this:
void BOOST_LOCAL_FUNCTION ( BOOST_BIND((factor)(&sum)), double num ) { sum += factor * num; std::clog<< "Summed:"<< sum<< std::endl; } BOOST_LOCAL_FUNCTION_DECL(add)
http://thread.gmane.org/gmane.comp.lib.boost.devel/168612/focus=168694
That is nice! -- end --
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.
IMO, what is moderate or complex programs and which tool to use to program them (Boost.Local, Phoenix, Lambda, etc) is a decision that should be left to our library users.
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.
I am sorry but I don't understand this. Can you please re-word it? Thanks a lot. --Lorenzo