Boost logo

Boost :

From: Marco Costalba (mcostalba_at_[hidden])
Date: 2008-05-20 13:11:17

On Tue, May 20, 2008 at 9:10 AM, shunsuke <pstade.mb_at_[hidden]> 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...


Boost list run by bdawes at, gregod at, cpdaniel at, john at