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: Lorenzo Caminiti (lorcaminiti_at_[hidden])
Date: 2013-03-18 11:43:34

On Fri, Mar 15, 2013 at 7:28 PM, Mostafa <mostafa_working_away_at_[hidden]> wrote:
> 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.

Mostafa, on which compiler did you try to compile the "dangling
definition" above in a local scope? As Steven also pointed out,
unfortunately this is not valid C++:

int main()
{ // local scope
    struct local_add
    {
        inline void body();
    };
    inline void local_add::body() // Invalid :(
    {
    }
    return 0;
}

>> 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.

There's a number of tricks in the implementation especially to pass
the local function as a template parameter and to speed up run-time...
sorry but you'll just have to dig into the code details if you are
interested about the internals of the library (there are code comments
that should illustrate at least the critical ideas in the code).

HTH,
--Lorenzo