|
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