Boost logo

Boost :

From: Marco Costalba (mcostalba_at_[hidden])
Date: 2008-05-17 01:39:21

On Fri, May 16, 2008 at 9:03 PM, Daniel Walker
<daniel.j.walker_at_[hidden]> wrote:
> It's still a vector of signatures. There are two kinds of signature
> here (by convention or protocol):
> * int(int, int) is the usual C/C++ call signature
> * plus(_1,_1) is our new emerging polymorphic signature by convention

Ok, now I understand, thanks, but still there is a fundamental
difference between int(int, int) and plus(_1,_1), namely the first
it's just an interface but the latter does real work, actually adds

I try to explain myself better with an example starting from the
normal functions case:

int add(int a, int b) { return a + b; }
int sub(int a, int b) { return a - b; }
bool is_positive(int a) { return a > 0; }
bool is_negative(int a) { return a < 0; }

msf::function<mpl::vector<int(int, int), bool(int)> > f(add, is_positive);

assert( f(3, 2) == 5);
assert( f(6) == true );

f = sub;
f = is_negative;

assert ( f(3, 2) == 1 );
assert( f(6) == false );

Ok. Simple. Now extend to polymorphic case:

struct add
    template<class T> T operator()(T a, T b) { return a + b; }

struct minus
    template<class T> T operator()(T a, T b) { return a - b; }

struct is_positive
    template<class T> bool operator()(T a) { return a > 0; }

struct is_negative
    template<class T> bool operator()(T a) { return a < 0; }

Now what I would expect for this generalization is:

msf::function<mpl::vector<_1(_1, _1), bool(_1)> > f(plus, is_positive);

assert( f(3, 2) == 5);
assert( f(3.5, 2.5) == 6.0);

assert( f(6) == true );
assert( f(6.7) == true );

f = minus;
f = is_negative;

assert ( f(3, 2) == 1 );
assert ( f(3.5, 2.5) == 1 );

assert( f(6) == false );
assert( f(6.7) == false );

So here we have:

msf::function<mpl::vector<_1(_1, _1), bool(_1)> >


msf::function<mpl::vector<plus(_1, _1), is_positive(_1)> >

because the vector of function signatures define the interface that
function should have to be wrapped by the overload set, as you prefer
to call it ;-), so also in polymorphic case the vector should keep
"polymorphic signatures" that different polymorphic classes with the
proper polymorphic signature should match to be _wrapped_ by the
overload set, not to be the underlying function, replacing
boost::function as you suggested.

In this case boost::function should be replaced by a wrapper of
polymorphic functors, not by _a_ polymorphic functor defined in
mpl::vector at msf::function instantiation.

Am I missing something?

BTW I don't even figure up how this wrapper of poly objects looks like
! or if it even exist.

>> This is _really_ totally different also from an implementation point
>> of view. Indeed a MSF boils down to a hierarchy of operator=() each
>> one defined on a given signature and each one forwarding to a
>> corresponding boost::function
> I started looking more closely at your implementation, and I like the
> way you do the class hierarchy. But the important part here is the
> hierarchy of operator()s right?

Yes. I meant that. It was a silly typo, I meant " a hierarchy of operator()"

> This won't compile yet, but the change I'm think of
> (starting from the version) would be something like

This is very old, now is out and in few hours it will be
out with the improved interface for poly objects, namely
the remove of set_polymorphic_object() and use of operator=() instead.

I suggest to download one of the above because they are very different
from the version you have.

> I'm sure there's more to it, but that gives you an idea. Of course,
> the first thing you need is an nary version of polymorphic_function.
> If you're serious about this and that's the direction you'd like to go
> in, I'd be glad to start working on it tomorrow!

Great!! I'm very interested in polymorphic generalization too, but I
would think is difficult stuff, too difficult for me alone ;-)


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