Re: [boost] Case study: Boost.Local versus Boost.Phoenix

Subject: Re: [boost] Case study: Boost.Local versus Boost.Phoenix
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2011-02-04 20:11:57

Phil Endecott wrote:
> The main complaint about that from the advocates of both Pheonix and
> Local seems to be that it's too far from the point of use.  Well, I
> have to ask how big your functions are, and if they're huge, why? 
> Also 
> do you dislike code like this:
> 
> void f1(args) { ........ }
> 
> void my_big_fn() {
>     ....
>     ....
>     ....
>     f1(a);  // using a function only to avoid duplicating the
>     f1(b);  // same code for a and b.
>     ....
> }
> 
> because the definition of f1 is far from where it's used?  Would you
> countenance using a macro instead:?
> 
> #define f1(arg) ....
> f1(a);
> f1(b);
> 
> Perhaps it comes down to this: we're used to functions being
> relatively 
> far from where they're used because it has always been like that, but
> we think of these lambda expressions as taking the place of the body
> of 
> a loop, and we're not used to that being out-of-line.

It isn't a matter of distance or familiarity, it is a matter of scope.  Let's look at the use case for local functions passed as arguments to other functions.  If the interace we are passing the function argument into isn't sufficiently generic we may not have access to the data we need through the arguments of the function we pass.  One way to work around this is to make the data global.  Now the function has acces to the data and can use it when it is called.  The problem with this is that we don't want a mess of global data.  If we instead declare the function as a local function it has access to the local scope data of the function in which it was declared when it is called from within the function to which it was passed.  Moving the function out of the local scope to the namespace scope means we have to move that data out of the local scope and into the namespace scope also.  That is objectionable and has serious implications for writing re-entrant code.

Regards,
Luke