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. 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.
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. 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 apologize for drifting somewhat off-topic from the original subject... - Jeff