Re: [boost] Any interest in dynamic dispatching mechanism from "interface" to template functions ?

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 
> 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