Re: [Implementation] Calling wrapped functions, converters, policies

Daniel Wallin <[email protected]> writes:

> Daniel Wallin wrote:
>> At 22:34 2003-10-05, David Abrahams wrote:
>> 
>>> Daniel Wallin <[email protected]> writes:
>>>
>>> > What's next? Should we start implementing this? Or did we
>>> > leave anything unresolved?
>>>
>>> I don't think so.  I'd love to get started on it.  I am rather short
>>> of time at the moment, but would be happy to act as "implementation
>>> guide/shepherd" or something ;-)
>> :) Ok great, I'll start working on it as soon as possible.
>
> I finally got started on the invoke/CallPolicies stuff. Right now I
> have:
>
>    - A function signature_of(F) which deduces the signature types of
>      a 
>
>      function pointer type and decomposes it into:
>
>         signature<Sequence, Tag>
>
>      Where Sequence := All types in the function signature, ordered in a
>                        way that is dependent on Tag.
>
>      signature_of((void(X::*)(int) const)0); for instance will create
>
>         signature<
>             mpl::vector3<const X&, void, int>
>           , signature_tag<
>                 true /* void_return */
>               , true /* member function */
>               , 3 /* arity */
>             >
>         >
>
> IIRC this is close to what you have in boost python today.

Yep, close.  It's missing the "hidden this downcasting" feature,
which we'll need.

>    - A CallPolicies concept which is a binary metafunction class that can
>      generate a converter for a type T and argument index N.

That sounds like a from-XXX converter generator, but not the full
concept that is CallPolicies in my mind, which includes converting
results to-XXX.

>         struct default_call_policies
>         {
>             template<class T, class Index>
>             struct apply;
>
>             typedef PyObject* argument_package; // in the python case
>             typedef /* .. */ state_type;
>         };
>
>      It also has the nested argument_package type. argument_package is
>      required to be constructible from the native argument_package type,
>      in this case PyObject*.
>
>      The nested state_type is the state that is passed to all
>      converters.

Very nice.

>    - generate_converter_tuple<Signature, CallPolicies>
>      Combines a given signature<> with a CallPolicies type and produces a
>      tuple type with converters that can perform the given conversion.
>
> and..
>
>    - A sample composite_call_policies<Seq> type that creates the
>      equivalent of map<Index, CallPolicy>. 

Do you really need random access over non-contiguous indices?  That's
what map<Index, ...> implies to me.

>      It also combines it's childrens argument_package types and
>      state types by inheritance.

Not sure what you mean by "by inheritance".

> I'm mostly trying to figure out the right interface for all this right
> now, so I have yet to check something in. But I think this seems to
> model what we decided before fairly well.

Sounds close.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com



-------------------------------------------------------
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl