Boost logo

Boost :

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>> writes:
>> The test driver code:
>> tests something similar;
>> 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

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


Boost list run by bdawes at, gregod at, cpdaniel at, john at