Boost logo

Boost :

From: Marco Costalba (mcostalba_at_[hidden])
Date: 2008-05-10 04:32:51


On Sat, May 10, 2008 at 3:17 AM, Giovanni Piero Deretta
<gpderetta_at_[hidden]> wrote:
>
> 1) can you dispatch on the dynamic type of an object? I.e.
>
> struct Base { virtual ~Base() {} };
>
> struct A : Base {};
> struct B : Base {};
>
> void foo1(A&);
> void foo2(B&);
>
> f = foo1;
> f = foo2;
>
> A a;
> B b;
> foo((Base&)a); // calls foo1
> foo((Base&)b); // calls foo2
>

Probably you mean

f((Base&)a); // calls foo1
f((Base&)b); // calls foo2

Anyway no you can't. But because also boost::function can't I fail to
see an inconsistency. Indeed

boost::function<int(A&)> f= foo1;

f((Base&)a); // calls foo1 <---- COMPILER ERROR: cannot convert
parameter 1 from Base to A&

>
> 2) If I have a polymorphic function object, can I store a single
> instance of this object
> and specify multiple signatures? i.e.
>
> struct foo_t { template<class T> void(T){...} } foo;
>

Sorry but the line

struct foo_t { template<class T> void(T){} } foo;

does not compile for me. Probably I'm missing something obvious.

I would like to point out a difference in behaviour with operator=()
of boost::function

In boost::function a relaxed 'compatibility' concept is used, i.e.
when assigning a function to a boost::function implicit type
conversions are taken in account, as example you can have

int foo(long);

boost::function<int (int)> f = foo;

Because an int argument can be converted to a long and the function
foo is considered 'compatible' with f.

This cannot be allowed in the multi signature case to avoid ambiguity
when there are more then one possible overload (please refer to
tutorial for further details). So in case of multi-signature
assignment operator= is based on a 'strictly compatible' concept
where, generally speaking, argument types must match. In this case
user should explicitly state to which function of the overload set to
bound foo. Again, please refer to tutorial.html for a detailed
explanation on how to do it.

Marco


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk