Re: [boost] Rave for proposed Boost.Local (functions)

Subject: Re: [boost] Rave for proposed Boost.Local (functions)
From: Lorenzo Caminiti (lorcaminiti_at_[hidden])
Date: 2011-02-05 12:20:07

On Wed, Feb 2, 2011 at 6:13 PM, Mathias Gaunard
<mathias.gaunard_at_[hidden]> wrote:
> The syntax to declare a local (I think nested would be a better name)

Yes, gcc calls local function "nested function" but WiKi computer
programming articles, Pascal, and Ada use "local functions" (I have
references in the library doc).

In one of the Rationale notes I indicate these as possible names:
1) Stay with Boost.Local.
2) Merge Boost.Local and Boost.ScopeExit into Boost.Scope (so to
retain the current BOOST_SCOPE_EXIT name and API but
BOOST_SCOPE_FUNCTION might not mean much...).
3) Boost.Nested for BOOST_NESTED_FUNCTION (good!) BOOST_NESTED_BLOCK
(I like it!) BOOST_NESTED_EXIT (maybe but BOOST_SCOPE_EXIT is better).

Anyways, this naming discussion can be resumed later if Boost.Local
moves forward :)

> function is not much more different than the one to define a regular
> monomorphic function, except you have to take care of capturing scope
> manually.
> I can tell from experience that I often end up writing by hand the very
> function objects that Boost.Local can automatically generate.
>
>
>> 2) Even though C++0x will support unnamed functions as a language feature,
>> Boost.Phoenix will not become obsolete. Quite the opposite, Boost.Phoenix
>> offers a lot of advantages over C++0x lambdas. (Forgive me if I won't go
>> into detail here about that, this thread is about Boost.Local)
>> Whereas Boost.Local are just a complicated way to express what can be done
>> with C++0x lambdas, I see no real advantage of Boost.Local over C++0x
>> lambdas.
>
> As far as I can see, there are few restriction compared to the equivalent
> C++0x lambdas:
>  - creating a local can only be done at statement scope.
>  - locals may not automatically capture all context
>  - size of a local function cannot be optimized to be two words.
>
> Let's compare Phoenix and that library and C++0x lambdas for a minute. Both
> C++0x lambdas and Boost.Local are better than Boost.Phoenix on several
> points.
>
> Doing anything non-trivial with Phoenix requires creating lazy functions
> beforehand (typically done at namespace scope).
> The fact that Phoenix itself bundles many lazy functions for any other
> container member and standard algorithm (for a total of 4,000 lines of code
> for that task alone) is testament to that; you can't really work with it
> otherwise.
>
> Bind and ->* can help to an extent (at the price of high verbosity), but if
> you want polymorphic behaviour (or don't want to specify manually all types
> involved) with template functions or members, you can't use those.
>
> This severely restricts Boost.Phoenix to being either used as a toy, or in a
> limited sub-world of C++ where naked classes, structures and functions don't
> exist, unless they've been adapted or wrapped to be used with it.
>
> On the other hand, C++0x lambdas can use arbitrary C++ syntax, and
> Boost.Local likewise, which means they can readily integrate in any source
> code.
> They cannot be polymorphic, but if that restriction were to be removed
> (through support for template member functions of local structures or
> otherwise), then the use for Phoenix would be even more limited.

What does "polymorphic" mean in this context? (I think it means that
the local functions cannot be template functions... right?)

-- 
Lorenzo