On Fri, Nov 25, 2011 at 7:11 PM, Nathan Ridge <zeratul976@hotmail.com> wrote:
From: mikhailberis@gmail.com
On Fri, Nov 25, 2011 at 6:06 PM, Nathan Ridge <zeratul976@hotmail.com> wrote:
And they won't support Boost.Local functions?
If Boost.Local functions are just function objects then sure. My point is that I don't see the need for Boost.Local for me to be able to leverage these libraries in C++03 or C++11.
Who ever said the point of Boost.Local was to be able to leverage these libraries?
So what was your point in asking the question in the first place?
The point of Boost.Local is to be able define functions locally, close to where they are used, with C++ statement syntax.
You mean using C++03 statement syntax of course. And "close to where they are used" is not the same as "where they are required". Like I said already before, the difference between 0 lines (Phoenix functions defined in-lined) and at least 1 line away (Boost.Local) is *infinite* compared to 1 line away for local functions and more lines away with non-local functions.
The arguments to the transformed and filtered adaptors are all C++11 lambdas defined immediately above these lines. How do you think this code would look if I instead dropped the lambda definitions inline? Or would you have wasted extra lines and time defining these little one-or-two-liner functions that are not used anywhere else, out of line?
I think You're Doing It Wrong (tm). If I was doing this, all these function objects would be types themselves, they would be testable outside this context, and they can even be just forward declared and linked statically later on.
I don't see why they need or have to be C++11 lambdas at all if they're not just a one-or-two liner and if they have names that do make sense as types.
They *are* one-or-two-liners, and it would be overkill to define them out of line.
So why are they even chained filters? Why not just: push_back(container, range | transformed([](element_type const & e) { // put all the logic right here } | filtered([](element_type const & e) { // put all the filtering logic right here }); Since you're already using C++11? Why even have the placeholder names in place at all if you don't need it anymore? I don't get it.
Now repeat this argument, substituting a class for namespace N, and two methods for A and B, and you have a use case for local functions.
No, I would create nested namespaces specific to the requirements of functions A and B (maybe call them impl_A and impl_B). There's no *need* for local functions in this case you're proposing.
Right, so now you're introducing a new construct (impl_A) just for this purpose, because you can't do the natural thing which is to just define the functions where they are used, i.e. inside A.
What if you were defining A inline in the class definition? How far would impl_A be from A?
So here's the thing: from a design perspective, why do you even need a local function at all? What would you need that local function for? Is it going to be a parameter to an STL algorithm? If so make it testable in isolation (from an engineering standpoint) and make it something that stands alone (from a design standpoint). Is it going to be called like a normal function? If so then why not make them normal functions that are not local and be done with it? If you really needed that function defined in-line as a lambda function then we already have libraries for that. I don't see what the need is for yet another library to do exactly the same thing.
Are you suggesting I propose it for the next standard of C++? That would be silly, as C++11 already has a solution (lambdas), and the whole point is to make the feature accessible to people who can't use C++11 yet.
See my point now?
Well that is precisely why we are proposing a library, and not a language feature - we already have the language feature, some people just can't use it yet!
But it's not lambda's you want to use, it's local functions (which aren't really even local functions) so there's no point in having this library at all!
Or are you suggesting that I propose a compiler-specific language extension for my compiler? That will not fly in an environment where one's code has to run of many different compilers, and in any case it goes completely against the spirit of having a language standard in the first place.
Right, so you see why I don't think Boost.Local even makes sense?
I'm sorry, I don't. While compiler-specific language extensions go against the spirit of having a language standard, libraries that emulate a language feature and work in standard C++ across platforms, such as Boost.Local, are very much in line with that spirit. This is what Boost has been doing with Foreach, Typeof, Lambda, etc.
So Foreach came at a time when there wasn't even a discussion on C++0x. Same for typeof, lambda, shared_ptr, etc. -- it's not the same situation now, where someone's proposing a library that's immediately antiquated and superseded by a language feature. *This* is why I don't think it even makes sense to have Boost.Local at all because, frankly, we've been fine without local functions since 2003 -- what's another couple of years?
So you admit that bad errors messages are a problem that users run into frequently, and that we're not likely to see a solution from the compiler side any time soon... but you say a library that solves this problem is not important enough for Boost?
Yes, they're not important enough for Boost if what it provides isn't compelling enough to be provided by Boost. If the only thing a library has is "prettier error messages when things are broken" then it's a great library for broken code -- which makes that advantage null and void because IT'S NOT AN ADVANTAGE BECAUSE YOUR CODE DOESN'T COMPILE.
Am I not getting through here?
Whoever loved a library that looked great when your code fails to compile? This is CRAZY TALK.
How often do you write code that is right the first time around?
Why does this matter?
Even for an experienced programmer, and especially with a new library, more often than not your code will initially be broken. To fix it, you need to understand the problem, and you need the library's help to do so.
This is anecdotal. Hardly convincing in a *logical* and *rational* standpoint.
So, since writing wrong code is just as much a reality of programming as writing working code, having a library that helps you fix your code when it's broken is just as important as having a library that runs your working code (OK, maybe not "just as important" - but quite important).
You got it wrong here: having a *compiler* that helps you fix your code when it's broken is what you want, not a library! *sigh* This is getting tiring because I just keep repeating myself. This is useless. Cheers -- Dean Michael Berris http://goo.gl/CKCJX