Boost logo

Boost :

Subject: Re: [boost] [local_function] End scope function name declaration makes code hard to read.
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2013-03-15 18:05:42


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. Is it possible to
> declare the function name at the beginning of the scope? (I don't mind
> having to also register the function name at the end of the scope.)
> Something like:
>
> BLF2(add, (int), (int lhs, int rhs))
> {
> return lhs + rhs;
> } BLF2_REGISTER(add);
>
> Having said, I don't see why needing an "ending macro" for the local
> function scope is a requirement (albeit my understanding of the library
> internals is limited to implementation annex of the documentation). Can't
> the start macro just expand to something like:
>
> //----------------------------**-
> //Macro Generated Output Start.
> //----------------------------**-
> //Local class definition.
> //Local class instance registration.
> //Out of class method definition starts here:
> inline void local_add::body(int& sum, const int& factor, const int& num)
> //----------------------------**-
> //Macro Generated Output End.
> //----------------------------**-
>
> //User generated content starts here:
> {
> return lhs + rhs;
> }
>

I'm wondering, can you be more specific in what the above would look like?

I believe the present implementation of local functions does something like
(very simplified)

struct xyz_struct : call_base { /*override*/ void call() // BEGIN macro
expansion
{ /* body provided by user between macro invocations */ }
} foo = {}; // END macro expansion

and I think clearly here the END macro needs to know the function name
("foo").

- Jeff


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk