On Fri, Nov 25, 2011 at 3:38 PM, Nathan Ridge <zeratul976@hotmail.com> wrote:
Stuff I (mikhailberis@gmail.com) said...
Huh? This is a matter of the rules of the programming language and (dare I say) sane engineering practices.
Are you saying it's sane engineering practice to avoid local functions? If so, why don't you avoid C++11 lambdas equally?
Because C++11 lambdas are function objects I can define in-line where I need function objects -- which is what modern C++ prefers over function pointers. The STL and every other sanely engineered C++ library that requires function object callbacks will support function objects whether they're defined in-line with C++11 lambdas or as hand-rolled function objects using operator() overloading. Also, I personally do not see a need for a construct like this: auto f = []() { /* do something here */ } I say this because there's absolutely 0 point in doing this if I can drop the lambda in where I need f *anyway*.
Did you really mean that C++ shouldn't stand in your way when you want to write Pascal code?
I don't know Pascal so I can't comment on that. I am saying that C++ shouldn't stand in my way when I want to make design choices like making one function local to another versus making them "equals" by putting them in the same scope.
What's the problem with making them equals? They're just functions.
I'm sorry but this logic is just broken. You're saying "I want local functions in C++ but I don't want it as a language extension". This makes no sense at all.
I do want it as a language extension. We have it as a language extension, it's called C++11 lambdas. But let's let the poor guys who can't use C++11 yet have an approximation of it, too!
Then propose/implement it as a language extension, or keep the current implementation and use it -- nobody's stopping you or anybody from doing that. Putting it in Boost is what I object to "just because".
But there are C++03 solutions, it involves functions in namespaces/class scope and binders. If you really want in-lined functions defined then you use an approximation of lambda's like Phoenix/Bind/Lambda in C++03.
The key word here being "approximation". Boost.Local is an approximation, too, just in a different way. Boost.Local gives you something Phoenix etc. do not (C++ statement syntax), and Phoenix etc. give you something Boost.Local does not (in-line definition in an expression context). Both approximations are useful, and some may prefer one over the other.
I know what gives me C++ statement syntax: C++ functions. I still don't get why local functions are so worth the trouble of muddying up a function's implementation when functions can stand alone anyway and be just as good.
Oh believe me they've heard it from me (or at least I've made some noise about it already). I can make more noise and maybe send in patches but there's other things in this world that concern me (and others) to actually do anything substantial in other fronts.
Could you point me to some links? I am genuinely interested.
Just this one: http://cplusplus-soup.com/2010/11/21/c-hating/ and look at the comments too if you have enough time. :)
Otherwise, you have to accept that library writers face a trade-off between the user-friendliness of error messages, and the expressiveness, terseness, and power obtained by extensive use of advanced techniques such as template metaprogramming. There is no one right answer to this tradeoff, and it is good for users to have different alternatives available to them.
Sure. So what's the point again? I don't see how this paragraph is relevant to the discussion.
You asked:
So again, how does broken code using any library become a basis for whether the library is a good library for inclusion in Boost? It just seems silly to me.
Since dealing frequently with errors is a reality of programming, and we cannot rely on compilers to substantially improve the readability of TMP error messages in the short term, a library that solves a similar problem to an existing library, but using different techniques that give rise to more user-friendly error messages, adds value, and therefore can reasonably be considered for inclusion in Boost.
No, sorry -- just having "prettier error messages" isn't a good measure for inclusion in Boost. You're going to have to try harder than that to make a case for a library. Cheers -- Dean Michael Berris http://goo.gl/CKCJX