On Sun, Sep 12, 2010 at 9:17 PM, Jeffrey Lee Hellrung, Jr. <jhellrung@ucla.edu> wrote:
On 9/12/2010 12:15 PM, Lorenzo Caminiti wrote:
On Sun, Sep 12, 2010 at 1:40 PM, John Bytheway <jbytheway+boost@gmail.com> wrote:
[...]
Anyway, the upshot of what I'm trying to say is: you may wish to make the compiler's life easier to head off efficiency concerns, and you should certainly do some profiling to measure the cost of a virtual function call in this context. But, all in all, it's a neat trick.
Yes, +1 on "neat trick". Based on other emails from Lorenzo, it looks like other similar libraries to proposed Boost.LocalFunction can either be encompassed by LocalFunction or trivially implemented in terms of it. I'm interested in the continued development.
I also think that, if this trick really works, it's a major plus for Boost.LocalFunction. Defining the function locally, close to the `std::for_each()` call (or similar algorithms) is an important use case for C++0x lambdas (see http://en.wikipedia.org/wiki/C%2B%2B0x#Lambda_functions_and_expressions). This can now be essentially covered by Boost.LocalFunction keeping the usual C++ syntax for the function body definition -- but with the limitation that the local function cannot be defined within the `std::for_each()` call (at the expression level) but it can be defined just before such a call (at the scope level).
2 very minor comments: First, I think the use of this_ is certainly an acceptable limitation, given that the alternative would be to use undefined (in, I'm guessing, a very practical sense) behavior. Second, I prefer the keyword "bind" (present) where you now use "bound" (past), but it's hardly a deal-breaker.
It's trivial to change from `bound` to `bind`, or any other word (but no symbols) for that matter. I just need Boosters to voice their opinions (more) on what this "keyword" should be. I also think `bind` is more readable but the past form `bound` might be more consistent with Boost.Parameter `deduced`... BTW, shall I use `closure` instead of `bind`/`bound`? Would `closure` make more sense in this context?
I understand your concern and suggestion. If this trick works and it makes it into Boost.LocalFunction, I will definitely consider performance optimizations.
I think this specific feature (ability to use a local function as a template parameter) could be very useful indeed.
Overall, I still think there's a place for this kind of functionality (LocalFunction) alongside Boost.Phoenix.
Yes, as mentioned before, the advantage of Boost.LocalFunction is to retain actual C++ syntax within the function body definition (but Boost.Phoenix and Boost.Lambda allows for "function" definition also at the expression level).
Question: Does LocalFunction provide any advantages over a named C++0x lambda, on those compilers that support such a construct? I can see the value of LocalFunction on compilers that don't have (or have buggy) C++0x lambdas, but what about those compilers that do have good support for C++0x lambdas?
I am NOT a lambda expert but I have been studying the topic since I started Boost.LocalFunction. As far as I know, no there is no advantage in using Boost.LocalFunction over C++0x named lambdas. On the contrary lambdas can be defined also at the expression level while Boost.LocalFunction cannot. Boosters, please correct me if I am wrong on this (especially given my shallow understanding of lambdas). -- Lorenzo