Subject: Re: [boost] Any interest in dynamic dispatching mechanism from "interface" to template functions ?
From: Larry Evans (cppljevans_at_[hidden])
Date: 2010-07-01 10:44:13
On 07/01/10 05:32, Raffi Enficiaud wrote:
> Hello all,
> The idea behind is not new and consists in dispatching a call of an
> interface function to the correct template instance, depending on the
> runtime or compile time parameters. The field of application is (to me)
> the release of static/dynamic libraries including functions with a
> set of types combination. This way, the library (compiled once) can
> easily be plugged to another framework or a script program (I personally
> use it with boost.python).
> An example of use could be (general idea, not a real code of course):
> // --------------
> template <class real_type>
> int template_function(real_type const& r_class1, double param_d, int&
> // ...
> return 0;
> int interface_function(MyInterface const* i_class1, variant const&
> param, variant& out)
> // return value
> int return_value;
> // constructs the dispatcher object with a reference to the values
> passed to interface_function
> dispatcher<int, MyInterface const*, variant const&, variant&>
> dispatch_object(return_value, i_class1, param, out);
> bool res = dispatch_object.calls_first(
> template_function < class_t1 >,
> template_function < class_t2 > //...
> if(res) return return_value;
> return -1;
> // --------------
> The dispatch_object tests for the convertibility of each instance ui of
> the arguments Ui of the interface function, with the corresponding
> argument Ti
> of the template function. The type of matching is defined by external
> objects, with a simple interface providing two methods: a convertibility
> test and a conversion.
> The types are "cleaned" in order to have a limited number of conversion
> It also includes a "back conversion" for Ui's that are non-const reference or pointers.
> I have checked a little bit the Boost.Vault but, correct me if I am
> wrong, the current dispatching mechanisms do not address exactly this
The test driver code:
tests something similar; however, it doesn't use fusion::vector
to store the argument references. Instead it uses:
The void* are cast to whatever the ArgTypes indicate
the actual variables types happen to be. However,
I'm not sure that's completely portable. OTOH,
one advantage, at least I think, is that the abstract
args and their corresponding concrete values can be
stored (or at least pointers to them) in the same
memory locations by just changing the ArgTypes... .
FWIW, I did try using a fusion container; however,
I was using one container for the abstract args,
and another for the concrete args, and pop_front'ing
from the abstract arg container while push_backing
to the concrete arg container, which I thought was
a bit of a waste.
Anyway, the dispatching code in reify_apply.hpp:
can be used for either a variant type structure
(like that in:
by using reifier_switch.hpp,
or one with virtual functions to do the dispatching, like
in the visitor pattern, as done with reifier_visitor.hpp.
The test driver uses either one based on the value of the
It differs from the apply_visitor in that it can be used
for any number of arguments, since sizeof...(ArgTypes)
can be any number.
What maybe different from your method, I think, is suggested
> The dispatch_object tests for the convertibility of each instance ui
> of the arguments Ui of the interface function, with the corresponding
> argument Ti
> of the template function.
I think that job is done by the:
in apply_unpack.hpp. I think mabye what you mean by:
> It also includes a "back conversion" for Ui's that are non-const
> reference or pointers.
is done by the:
in void_ptr_array::project in replace_source_with_target_ptr.hpp.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk