Re: [boost] [local_function] passing local functions as template parameters

Subject: Re: [boost] [local_function] passing local functions as template parameters
From: Jeffrey Lee Hellrung, Jr. (jhellrung_at_[hidden])
Date: 2010-09-12 21:17:49

On 9/12/2010 12:15 PM, Lorenzo Caminiti wrote:
> On Sun, Sep 12, 2010 at 1:40 PM, John Bytheway
> <jbytheway+boost_at_[hidden]>  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