Re: Re: [C++-sig] [Implementation] Calling wrapped functions, converters, policies

At 15:57 2003-09-20, David Abrahams wrote:
>Daniel Wallin <[email protected]> writes:
>
> > Sounds good. I actually wrote something like this yesterday morning, except
> > I used the ConverterGenerator type instead of a nested type and I didn't
> > think about passing the entire state tuple to the converters.
> >
> >    typename context_type<Policies>::type context(policies);
> >
> >    typedef typename find_converter_generator<Policies, 1>::type c1_gt;
> >    typename c1_gt::template apply<T0, xxx_to_cpp>::type c1;
> >
> >    typedef typename find_converter_generator<Policies, 2>::type c2_gt;
> >    typename c2_gt::template apply<T1, xxx_to_cpp>::type c2;
> >
> >    context.precall(params);
> >
> >    c1.convert(params[0], context.get((c1_gt*)0));
> >    c2.convert(params[1], context.get((c2_gt*)0));
> >                          ^^^^^^^^^^^^^^^^^
> >    context.postcall(params);
>
>I've been thinking of something a little bit different.  See below.
>
> > Anyway, this seems great. Perhaps the requirements on
> > ConverterGenerators/CallPolicies
> > can be quite loose too;
> >
> >    May or may not contain a 'state' typedef.
> >        - has_xxx
> >
> >    The state typedef may or may not be a mpl sequence.
> >        - is_sequence
>
>Bad idea, IMO.  Not all compilers support has_xxx, defaults
>(e.g. typedef mpl::vector0 state) are easy to come by through
>inheritance, and every metafunction invocation has a cost in compile
>time.  I'd rather just establish a simple set of requirements.
>
>
>Now, I know you've been thinking about things from the level of
>policy composition by putting together things like
>
>        adopt(_1,_2) + release(_4)
>
>or whatever syntax it is that you use.  I support using that sort of
>construct, but I want to look at things from the low-level
>implementation perspective of the invocation of the wrapped entity for
>a moment.
>
>One thing I discovered in trying to wrap factory functions as
>constructors is that converters need access to the whole incoming
>argument list, because the converter for parameter N of the called
>function really needs to operate on parameter N+1 of the input (the
>initial "self" argument is dropped).  I believe this is also the way
>per-argument (or rather, per-converter) precall actions should be
>handled - converters can just do the precall action in their convert()
>functions.  The only capability lost from the current precall protocol
>is the ability to fail overload resolution at that point, but I've
>only ever used precall for one thing, and it never needed to fail
>overload resolution so I don't believe it's important.

Does the converter really need access to the whole argument list? I don't
see why, at least if we do the "filtering" before passing it into the converter
function. I thought this is what you are doing in Boost.Python with the
new changes, but I could have misunderstood.

><snip>
>Anything I'm missing?  Your thoughts?

No I think that about covers it. The current implementation (in luabind, 
and some
of langbinding..) doesn't use tag-dispatching for the invoke functions, but 
I guess
there are reasons that tag-dispatch is better than class specialization here.

BTW, does Boost.Python handle const functions/objects? In luabind we do, so
I guess we would need const to be part of the function signature type.

---
Daniel Wallin



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf