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

Subject: Re: [boost] Rave for proposed Boost.Local (functions)
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2011-02-02 18:13:42

On 02/02/2011 13:21, Thomas Heller wrote:

> Point taken.
> OTOH the macros used to define the local functions are not even close to
> those of either C++0x lambdas or regular C++ functions.

I find them pretty close to both, except you need to explicitly 
enumerate variables you wish to bind. (C++0x lambdas do it do, but also 
have a mode where it captures everything)

> The "fluff" and "obfuscated" syntax you find in Phoenix et al in the body of
> the expressions, was shifted in Boost.Local to the function decelerator.

Right, and that's a good thing.
The body of a function is its important part; that's what you want to be 
lightweight, clear, expressive and debuggable.

The syntax to declare a local (I think nested would be a better name) 
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.

I see Boost.Local as merely an emulation for C++0x-like lambdas; it can 
be used to make code compatible with C++03.

In truth, I believe Boost.Local is useful to a much broader audience 
than Phoenix, and is therefore as worthy of being a Boost library. There 
is also a lot of precedent in libraries that allow C++0x features in C++03.