On 11/02/11 18:19, Lorenzo Caminiti wrote:
On Thu, Feb 10, 2011 at 4:13 PM, John Bytheway <jbytheway+boost@gmail.com> 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