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 21:30:08

On 07/01/10 17:48, Raffi Enficiaud wrote:
 > Larry Evans <cppljevans <at> suddenlink.net> writes:
 >
 >
 >> The test driver code:
 >>
 >> http://preview.tinyurl.com/2a9dlun
 >>
 >> tests something similar;
[snip]
 >> 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.
 >
 > Almost, but not exactly. For instance line 83 of
 > apply_unpack.hpp:
 >
 > typename function_types::
 > can_be_called<Functor(Args const&...)>::type
 > is_ftor_args_callable;
 >
 > The fact is that the Functor itself is not always
 > directly callable with the Args, and there is two
 > sequences of Args that should be considered: the one
 > for the interface and the other for the arguments of
 > the template function. So the
 > level of indirection induced by the convertors
 > mentioned earlier should be considered.
 > For instance a base class pointer to a derived class
 > reference (again... :) ). All these logics are
 > embedded in the convertors, defined for each
 > pair of types (interface, concrete), which make it
 > very easy to extend to new types.
 >

Ah!  This is was I was missing.  IOW, dispatch_object must know the
signature ( argument types) of 2 functions, the interface function and
the template function and attempt conversions between corresponding
argument types.  In contrast, reify_apply simply converts each
"abstract" argument to it's actual "concrete" value before 1st
checking that the concrete values are consistent (using
apply_ftor_check_args) with the Functor.  IOW, there's just one
function (or Functor) in reify_apply's case, and that's not examined
until all conversions are done because only a runtime value of the
abstract objects(the tag value in case of the reifier_switch and the
virtual function table in the case of reifier_visitor) are used to
convert to the concrete objects; whereas, with dispatch_object, 2
functions are used and the signatures of both are used to guide the
conversion.

[snip]
 >
 >> 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
 >>
 > So here again, I think there is a need for an indirection
 > level. The conversion is not always static (std::map& to
 > variant& for instance). But maybe I missed some point ?

I think maybe the problem is, as mentioned above, reify_apply
solves a somewhat different problem than dispatch_object.

 >
 >
 > Thanks for your feedback !

You're welcome!

-regards,
Larry