On Tue, May 20, 2008 at 9:10 AM, shunsuke <pstade.mb@gmail.com> wrote:
struct g { template<class> struct result; template<class T> struct result<g(T)> { typedef T type; }; T operator(T t) { return t; } };
This is a good poly wrapper start. It would be real generic it if was: struct g { template<class> struct result; template<class T> struct result<g(T)> { typedef T type; }; T operator(T t) { return bounded_poly_functor(t); } }; where bounded_poly_functor is what is assigned to the overload_set with operator=(), or insert() as you called it.
overload_set<char(char), int(int), g(_1)> h;
If the 'g' was a real wrapper you don't need to explicit write in overload_set template parameters as long as you don't need to explicit write boost::function wrapper type in normal cases.
h.insert(&f<char>);
The above is really the key of all this stuff. If you are able to do that then perhaps poly wrapper is more real then what I have supposed. Just tho be clear, I imagine that after the above instruction bounded_poly_functor variable becomes 'f' or something similar (read a pointer) to 'f'
// type-erasure bound to int(int) h.insert(function<int(int)>(g()));
This is useless IMHO if 'g' it's just a poly wrapper. I think the key point that is still not completely clear to me is to understand if you think that g() has some functionality apart from forwarding arguments or it's just a wrapper as boost::function is a wrapper for normal functions.
// polymorphic g bound to g(_1) h.insert(g());
BTW, what if `g(_1)` means templated function returning `g` type?
That's very natural. For this reason and because g would be supposed to be by just a wrapper with no functionality but forwarding arguments a better naming IMHO could be _1(_1) where the first _1 is the return type, or a standard name like egg:poly_wapper(_1) or msf::polymorphic(_1). Just examples.
I'm reading that thread. The motivation and role seems different. For example,
struct IfInt { ... }; // a function object type struct Otherwise { ... }; // a function object type
/* It is cumbersome to write down something like this: struct F_ { void operator()(int x) { IfInt()(x); }; void operator()(any x) { Otherwise()(x); }; }; */ // Hence, Egg provides a helper to build overloaded function in one shot. static_<result_of_overload<IfInt(int), Otherwise(_)>::type>::type const f = {{}}; // BTW, f is empty.
Yes. I agree this is different. In your case you pass real functionality in result_of_overload<> template parameters, because IfInt and Otherwise do something. Instead, if I have undersood correctly Daniel, 'g', as he called it, should be just a wrapper, an argument forwarder. It doesn't even need to be explicit in the template a parameters.
As suggested, I feel container-like behavior is not a job of multi_signature_function, though.
I would feel the same... Thanks Marco