
Boost : 
From: Marco Costalba (mcostalba_at_[hidden])
Date: 20080517 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
stuff.
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)> >
not
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 msf_27_4_2008.zip version) would be something like
>
This is very old, now is out msf1.1.zip and in few hours it will be
out msf1.2.zip 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 ;)
Marco
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk