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 predefined 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& param_out) { // ... 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( fusion::vector_tie( 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 structures. [snip] It also includes a "back conversion" for Ui's that are non-const reference or pointers. [snip] 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 issue. [snip] The test driver code:
http://preview.tinyurl.com/2a9dlun tests something similar; however, it doesn't use fusion::vector to store the argument references. Instead it uses: template<typename... ArgTypes> struct void_ptr_array { void* my_ptrs[sizeof...(ArgTypes>; ... }; 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: http://preview.tinyurl.com/2ah2kpx can be used for either a variant type structure (like that in: variadic_templates/boost/composite_storage/pack/container_one_of_maybe.hpp ) 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 REIFIER_VISITOR macro. 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 by:
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: apply_ftor_check_args 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: arg_type*ap=static_cast<arg_type*>(vp); return *ap; in void_ptr_array::project in replace_source_with_target_ptr.hpp. -regards, Larry