On Fri, Nov 25, 2011 at 9:20 PM, Lorenzo Caminiti <lorcaminiti@gmail.com> wrote:
On Thu, Nov 24, 2011 at 9:53 PM, Dean Michael Berris <mikhailberis@gmail.com> wrote:
Not just that. It's also because it's trying to approximate something limited as compared to what C++11 already has.
a) OK, I think I understand. My reply if that if Boost.Local does not approximate well C++11 lambdas because it cannot be define within expressions, it instead approximates well named lambdas which are closures defined at declaration scope:
int a; auto localf = [&a](int z) { ... // lots of instructions here };
This C++11 construct is well approximated by the following in C++03:
int a; void BOOST_LOCAL_FUNCTION(int z, bind& a) { ... // lots of instructions here } BOOST_LOCAL_FUNCTION_END(localf)
Sorry, I don't think you *do* get it. Named lambda functions are an oxymoron. When you give a name to a function, it ceases to be a nameless function. The *utility* of having a function defined inside another function is marginal at best because they're absolutely better outside any other functions in all aspects: readability, maintainability, and functionality. There's *no* practical reason to put a lambda in a named variable when the point of lambda's are so that you can define them in-line. I would even say that it's bad practice to do this at all in C++11 code for a lot of reasons: auto f = [](...) { /* whatever */ }; Some of the reasons are: 1) This messes up ADL and would lead to hard-to-find bugs. 2) You're cluttering the function definition with logic that's supposed to not even be in the same function. 3) It's not a real function that can be referred to via function pointers. Is that clear enough for you?
b) Other libraries like the recently reviewed Boost.Algorithm and Boost.Atomic implement C++11 features for C++03. I would expect the ability of Boost.Local to implement C++11 named lambdas (i.e., local functions) for C++03 to be just as valuable. Why wouldn't it?
There's a difference between a back-port like in the case of Boost.Algorithm, Boost.Atomic, and Boost.Unique_ptr, drop-in (forwardable) approximations like Boost.Move, and a very narrow and marginally useful approximation like what Boost.Local provides. Does that make it clearer? Cheers -- Dean Michael Berris http://goo.gl/CKCJX