Re: [boost] [local] Simplifying the parenthesized syntax

Subject: Re: [boost] [local] Simplifying the parenthesized syntax
From: John Bytheway (jbytheway+boost_at_[hidden])
Date: 2011-02-11 15:36:40

On 11/02/11 18:19, Lorenzo Caminiti wrote:
> On Thu, Feb 10, 2011 at 4:13 PM, John Bytheway
> <jbytheway+boost_at_[hidden]> wrote:
>> You shouldn't need to use Typeof if you extract the return type in the
>> manner Steven Watanabe suggested:
> 
> Also I think I have figured out a way for the PARAMS/NAME macros to
> support recursive calls so I am thinking not to provide the
> parenthesized syntax macros at all.
<snip>
>     // The macro:
>     //
>     //  BOOST_LOCAL_FUNCTION_NAME(factorial)
>     //
>     // Expands to code equivalent to the following. Note:
>     //
>     // * Use function name `factorial` to generate unique symbols.
>     // * Function name `factorial` available.
>     // * None of the `..._29` symbols are available (different __LINE__).
> 
>     // Public so it can be used to deduce local::function<> type to define
>     // functor that can be passed as template parameter.
>     public:
>         // Member with function name for recursive calls. This cannot be
>         // defined sooner because the function name is only available here.
>         ::boost::local::function_ref<function_type_29, 1> factorial;
>         // Cannot be programmed in the constructor because it also sets the
>         // `factorial` member with name only known in this macro expansion.
>         void init(void* bind_params) {
>             binds = static_cast<binds_29*>(bind_params);

I'm puzzled; you say "None of the `..._29` symbols are available" but
you're using both function_type_29 and binds_29 here...

>             factorial = *this; // For recursion.
>         }
>     } object_factorial;
>     object_factorial.init(boost_local_auxXargs.value);
>     BOOST_TYPEOF(object_factorial.factorial) factorial(object_factorial);

I imagine you can get rid of this TYPEOF call with function_traits too
(with e.g. an appropriately defined member function in object_factorial?).

> BTW, is there value in making functor_29's operator() and/or body
> functions inline?

It depends what you mean by "making" them inline.  They're class member
functions defined in a class body, so they're already *declared* inline.
 Adding the inline keyword will make no difference.

However, IIRC from my previous experiments icc will not inline the
virtual call through local::function<>, even though I think the standard
allows it (and if icc won't do it, I doubt many other compilers will),
so in practice they won't actually be inline (but should have only one
indirection, which is good).

I think two questions remain for you to consider:

1. Might anyone might want them *not* to be inline, because they're
afraid of code bloat, and their compiler optimizer is so clever that it
will inline them?  I doubt this is an issue because (a) I don't know a
compiler that clever and (b) a compiler that clever should be taking the
risk of code bloat into effect.

2. Might anyone care so much about performance that they absolutely must
have the code inlined?  The answer is probably "yes" (or at least there
will be people who *think* they care, which is also a problem).  For
these people you could, if you choose, provide an alternate
implementation which doesn't indirect through local::function<>, and
thus will only work in C++0x (or C++03 with non-standard extensions).

Regardless, as I said last time, you should do some profiling and put
the results in your docs so that both you and your users can make
informed decisions.

John Bytheway