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