Re: [boost] Simple object factory: Checking signatures at runtime

From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2007-09-06 14:23:14

Hi Marco,

On 9/6/07, Marco Costalba <mcostalba_at_[hidden]> wrote:
> On 9/6/07, Dean Michael Berris <mikhailberis_at_[hidden]> wrote:
>
> > I'm looking for a similar solution, but more towards improving
> > http://dispatcher.sourceforge.net/ to be able to support multiple
> > function signatures in a single dispatcher instance. I think I've got
> > a way to accomplish that with Boost.Fusion, but I doubt this same
> > approach you propose will work for runtime determination.
> >
> > Unless I'm missing something, in which case please enlighten me.
> >
>
> I studied your dispatcher code. The "trick" is that it supports only
> one signature per dispatcher. So that all the objects stored your maps
> could be easily derived form a base class with a given and fixed
> signature.
>

This is by design to enable coherent code which in place of a switch()
{...} allows you to dispatch functions which are registered during
runtime instead of just being statically defined at compile time.
Consider how Boost.Signals does it by making it simple to have a
homogeneous container of functions that got signalled when a message
is passed to it -- only Boost.Signals is an excellent implementation
of the publish-subscribe channel pattern, whereas the dispatcher is
meant to be an implementation of a message router pattern.

> When you want to store objects with different signatures in a single
> map you need (or at least I was not able to find something better ;-)
> to use a common base class with no signature information
> (StorableClass) and store pointers of that class, then you add
> signature info subclassing that class with a class templetized on a
> given signature (SignatureClass).
>
> So you have a possible map:
>
> map[(key1,p1)  (key2,p2)  (key3,p3) .... ]
>
> where pointers
>
> StorableClass *p1, *p2, *p3 are indeed pointers to objects of 3
> different instances of a template<>SignatureClass
>
> So pointers can coexist together also if the objects they point have
> different signatures. In the "simple_factory.hpp" example, I posted in
> a previous thread, a dynamic_cast at runtime is used to check the
> signatures hidden behind p1,p2,p3 against a given one.
>
> The real problem is that two SignatureClass objects with different signatures:
>
> SignatureClass<int (int,int)> and SignatureClass<int (int,double)>
>
> HAVE DIFFERENT TYPE!!! so that a dynamic_cast is unable to discover
> that a set of values v1,v2 that could be used for the first one can be
> feed also to the second one.
>
> Hope is clear...at least a bit ;-)
>

In this case, I think the approach I will take will be a bit more
different that what you have chosen to do. Since I plan to do
something like:

void foo(int a) { ... };
void bar(int a, int b) { ... };
void foobar(int a, double b) { ... };

dispatcher< fusion::vector<void(int), void(int,int), void(int, double)> > d;
d[0] = &foo;
d[0] = &bar;
d[0] = &foobar;

If you look at the implementation(s) for the "functor" type in the
dispatcher, it would be possible for it to provide the three
operator() overloads following signatures given as a fusion::vector<>
by containing three boost::function<>'s each having one signature, and
having the deduction done during compile-time still. So that means:

d[0](1); // foo() is called
d[0](1, 2); // bar() is called
d[0](1, 2.1); // foobar() is called

This will be possible since the dispatcher's operator[] will return a
reference to a 'functor' instance which overloads operator() following
the many signatures it is configured to support. I think Boost.Fusion
will definitely help in this extension through the fold<>
algorithm/metafunction (for linear inheritance for the signature
overloads).

Although I'm not a Boost.Fusion expert, I'm pretty confident it's just
a matter of sitting down and actually getting things to work the way I
want them to work. I'm also right now (at least initially) convinced
that this is actually feasible. ;)

-- 
Dean Michael C. Berris
http://cplusplus-soup.blogspot.com/
mikhailberis AT gmail DOT com
[phone]