Boost logo

Boost :

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 21:48:46

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. 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);
> To repeat the name is a bad idea because you duplicate that
> information. Just use a code comment after the result type to do that:
> void /* add */ BOOST_LOCAL_FUNCTION(const bind factor, bind& sum,
> int num) {
> sum += factor * num;
> HTH,
> --Lorenzo

(I am going to respond in two posts, since the discussion will most likely
split into two subthreads.) Thanks, unfortunately I think this is a worst
idea. It's very easy for the comment and the code to get out of sync and
there's no way the compiler will catch it, and anyways you're still
duplicating information. With the alternative, I believe there is a way to
jerry-rig a compiler error if the beginning and ending function names
don't match (given my limited understanding of the implementation). The
first macro will incorporate the function name into the name of the
registering object, and the second second macro will incorporate the
function name into the name of the local functor object, and will register
the latter with the former. Using the example in the implementation annex,
this is what it would like (yes, it may not be too wise to use that
example, but in the absence of an alternative that's the best I can come
up with):

//First Macro.
BLF2(add, (int), (int lhs, int rhs)) expands to:

//Some stuff
//Declare but don't initialize the registering object:
casting_func add_casting;

//Second Macro
//BLF2_REGISTER(add) expands to:

//Some other stuff
//Register the local functor object using the object expanded to by the
beginning macro
add_casting.register(&add_local, &local_add::call);

Hence, if there's any misspelling of the function name in either of the
macros, a compiler error should ensue. (Anyways, I think my second post
might make this entire exercise moot.)



Boost list run by bdawes at, gregod at, cpdaniel at, john at