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

Subject: Re: [boost] [local_function] passing local functions as template parameters
From: Lorenzo Caminiti (lorcaminiti_at_[hidden])
Date: 2010-09-12 23:06:51

On Sun, Sep 12, 2010 at 9:17 PM, Jeffrey Lee Hellrung, Jr.
<jhellrung_at_[hidden]> wrote:
> 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.

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