On Wed, Feb 2, 2011 at 6:13 PM, Mathias Gaunard <mathias.gaunard@ens-lyon.org> 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