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-15 22:04:27

On Fri, Mar 15, 2013 at 6:48 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. 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;
>>     } BOOST_LOCAL_FUNCTION_NAME(add)
>>
>> 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:

Again, I won't provide this API because it duplicates the local
function name given that the name is necessary for the ending macro
(if you want the name at the beginning, where it is neither necessary
nor sufficient, use a code comment, program your own macro that
duplicate the information, etc).

> //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.)
>
>
> Thanks,
>
> Mostafa
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost

-- 
--Lorenzo