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

16 Mar 2013


      On Fri, 15 Mar 2013 15:20:32 -0700, Lorenzo Caminiti  
 wrote:
...
On Fri, Mar 15, 2013 at 2:33 PM, Mostafa  
 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_loca...
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(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