On 19/11/11 01:59, Lorenzo Caminiti wrote:
On Fri, Nov 18, 2011 at 6:53 PM, John Bytheway <jbytheway+boost@gmail.com> wrote:
How feasible would it be to allow overload to be used without declaring all the function types. So, your example:
boost::local::function::overload< void (const std::string&) , void (const double&) // Overload 1st param type. , void (const double&, const char*) // Overload giving default param. , int (int, int) // Overload giving 2 params (from function pointer).
print(print_string, print_double, print_double, print_add);
might be written instead:
auto print = make_overload(print_string, print_double, print_double, print_add);
Yes, this should be possible. I will experiment with it and eventually provide make_overload for convenience.
(with suitable use of BOOST_AUTO for C++03). I guess this only works if all the functors passed are monomorphic and expose (or could be made to expose) their argument types, but that covers function pointers, boost::function objects, and Boost.Local functions, which is a fairly wide applicability.
Writing the above inspires me to ask: Do Boost.Local functions expose their argument types and return types at compile time? If there is a widely accepted way for monomorphic functors to do so, then they should. If there is no such widely accepted way, then one should be created, but that's probably not a job for you right now :).
What do you mean? How would this feature look like for Boost.Local? (Sorry if I am not following...)
Note how a boost::function object defines a static const int arity, and types arg1_type, ..., argN_type. You need this sort of information if you are to implement something like the above make_overload and accept a 'generic' function object. I feel that there should be some widely accepted way to present the interface of a monomorphic function object for introspection. I don't particularly like the way that has been chosen by Boost.Function. But I'm not aware of any other.
* Introduction
"the object this can be bound (eventually by constant value" - I don't understand "eventually".
It means that you can either "bind this" or "const bind this" (the second binds the object as constant within the local functions even if the object is non-const in the enclosing member function). I will make this text more clear.
As was pointed out elsewhere, I think this is a translation issue. "eventually" doesn't make sense here. You might mean "possibly" or "perhaps"?
"The maximum number of parameters that can be passed to a local function (excluding eventual bound variables)" - I don't understand "eventual".
It means that the max number of parameters does not include the bindings. In other words, if the max number of parameters is 5 then you can write local functions with up to 5 parameters and as many bindings as you want PARAMS(int a1, int a2, int a3, int a4, int a5, bind x1, bind x2, ..., bind x100). It says "eventual" because there might or not be binds. I will make this text more clear.
Here I'd say "any" instead of "eventual", or just nothing at all.
"Compilers have not been observed to be able to inline recursive local function calls (not even when the recursive local function is also declared inlined)." - do you mean "not only when"?
I mean NAME(inline recursive f) still wasn't observed to inline.
Yes, your wording is correct. I misread it.
* Macro BOOST_IDENTITY_TYPE
I don't understand the "Warning" at the bottom; can you expand?
This works:
template<typename K, typename V> void f ( std::map<K, V> m ) {}
int main() { std::map<char*, int> m; f(m); return 0; }
But this doesn't:
template<typename K, typename V> void f ( typename BOOST_IDENTITY_TYPE((std::map<K, V>)) m ) {}
int main() { std::map<char*, int> m; f(m); return 0; }
In this case you have to explicitly write f<char*, int>(m); in main :( .. Note that this is never a problem for local functions because (unfortunately) they cannot be templates. However, given that IDENTITY_TYPE is shown here as a general purpose macro this is a limitation of the macro for the general case.
I will add this example to the docs to clarify.
I see. Yes, the example will help. John