Re: [boost] [local_function] End scope function name declaration makes code hard to read.

Subject: Re: [boost] [local_function] End scope function name declaration makes code hard to read.
From: Mostafa (mostafa_working_away_at_[hidden])
Date: 2013-03-15 22:28:28

On Fri, 15 Mar 2013 15:20:32 -0700, Lorenzo Caminiti  
<lorcaminiti_at_[hidden]> wrote:

> On Fri, Mar 15, 2013 at 2:33 PM, Mostafa  
> <mostafa_working_away_at_[hidden]> wrote:
>> (This is a feature request/inquiry.)
>>
>> I'm just now seriously starting to use local_function, and I'm finding  
>> that
>> having to "visually parse" until the end of scope to determine the local
>> function name makes the code much harder to read.[snip]
>> Having said, I don't see why needing an "ending macro" for the local
>> function scope is a requirement
>
> [5] Rationale. The local function name must be passed to the macro
> BOOST_LOCAL_FUNCTION_NAME ending the function definition so this macro
> can declare a local variable with the local function name to hold the
> local function object. Therefore the local function name cannot be
> specified within the BOOST_LOCAL_FUNCTION and it must appear instead
> after the local function body (even if that differs from the usual C++
> function declaration syntax).
>
> http://www.boost.org/doc/libs/1_53_0/libs/local_function/doc/html/boost_localfunction/tutorial.html#ftn.boost_localfunction.tutorial.local_functions.f0

Maybe I wasn't too clear in my original post. I can't see why the method  
body can't be defined after the local function object variable  
declaration. Declare, but don't define the method in the local class, and  
then at the very end of all which the first macro expands to, "define" the  
said method without the method body. So when the user completes the first  
macro with "{ ... blah ...}", the latter completes the method definition.  
Hence, no need for a second macro. For lack of a better example, I will  
use the same example from implementation annex:

#define BFL2(add, (void), (const bind factor, bind& sum, int num)) \
     struct local_add : virtual_func::interface { \
         explicit local_add(int& _sum, const int& _factor) \
                 : sum_(_sum), factor_(_factor) {} \
         inline void operator()(const int& num) { \
             body(sum_, factor_, num); \
         } \
         inline static void call(void* obj, const int& num) { \
             local_add* self = static_cast<local_add*>(obj); \
             self->body(self->sum_, self->factor_, num); \
         } \
     private: \
         int& sum_; \
         const int& factor_; \
         inline void body(int& sum, const int& factor, const int& num); \
     } add_local(sum, factor); \
     casting_func add_casting(&add_local, &local_add::call); \
     \
     //DANGLING DEFINITION \
     inline void local_add::body(int& sum, const int& factor, const int&  
num)

//Usage:
BFL2(add, (void), (const bind factor, bind& sum, int num))
{
     sum += factor * num;
}

Note the "DANGLING DEFINITION" section.

> Unfortunately not :( The Implementation section is just a very
> simplified example of what the macros generate:
>
> Note
> The code listed here can be used by curious readers and library
> maintainers as a reference in trying to understand the library source
> code. There is absolutely no guarantee that the library implementation
> uses the exact code listed here.
>
> Look at the source code, there are a couple of code comments that
> mention "here's why the name is needed here" but you have to dig into
> the code...
> [snip]
> HTH,
> --Lorenzo

Yes, I did see that, and did do "some" looking into the source. I was  
hoping to short-circuit some of that research with your insights.

Thanks,

Mostafa