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

Daniel Wallin <[email protected]> writes:

> At 03:58 2003-09-21, David Abrahams wrote:
>>David Abrahams <[email protected]> writes:
>>
>> > I'd like to see a templated protocol to access the actual
>> > argument list, e.g.:
>> >
>> >      get<1>(args)  ->  "argument 1"
>> >
>> > we'd define a get<> which operates on PyObject* (argument tuples) but
>> > we could also wrap the argument tuple in a kind of mapping to drop the
>> > first argument (or inject a faux argument, in the case of an out
>> > parameter which doesn't actually appear in the incoming argument
>> > list).  For handling lone conversions (like extract<T>(obj)) we could
>> > wrap a single PyObject* (argument) in a class for which only get<0>(x)
>> > (but not get<1>, get<2>,...) was defined.
>>
>>Still another possibility is to tie the interface into the
>>CallPolicies, which would eliminate some questions about where users
>>who define new policies customize (and would let constructor_policy
>>continue to use PyObject* as an argument_package, but then requires
>>the CallPolicies to be passed to the converters (ugly).
>
> Hm.. I don't think I understand why the converters would need CallPolicies.

1. I want the converters to have access to the entire argument
   package, rather than being passed a single argument.

2. If the method of getting argument #N from the package is tied to
   the CallPolicies, e.g. via a member or static function, then
   naturally you need an instance of the CallPolicies or at least its
   type in the converters.

>>Still another
>>possibility is to require a class type with member get/arity for
>>argument_package.
>>
>>Thoughts?
>
> Yeah, it looks good. I guess we would need to complicate things a bit though,
> since we don't have inheritance from our base policy:

One might ask "why not?"  After all, your slick interface doesn't
preclude inheritance as an implementation detail.

>
>    struct CallPolicy
>    {
>       template<class Base>
>       struct argument_package
>       {
>         typedef /* .. */ type; // perhaps this doesn't need to be a
>         metafunction..
>       };
>    };
>
>    typedef typename LanguageDescriptor::argument_package arg_pk0;
>    typedef typename call_policy0::template
>    argument_package<arg_pk0>::type arg_pkg1;
>    typedef typename call_policy1::template
>    argument_package<arg_pk1>::type arg_pkg2;

Just require ArgumentPackage types to have templated constructors and
you can avoid all this multi-step hoo-ha.  You can pass a
LanguageDescriptor::argument_package straight through to the innermost
member or base class.

>    arg_pk2 argument_package(arg_pk1(args_));
>
>    f( c0.convert( argument_package.get(mpl::int_<1>()) ));
>
> Also keeping the get() function in the argument_package type seems
> simpler to me.

It has two negative implications:

   1. I can't just pass around PyObject* in the usual case, which is
      likely to be more efficient.  Few compilers still pass classes
      in registers.

   2. The syntax for invoking get becomes ugly:

         args.template get<3>()

      I don't care so much for myself, but writers of custom policies
      will have to touch that syntax too.

> We would probably need to wrap your PyObject* args in a class type
> anyway, so that we can have a single access point to
> args/self/result.

Huh?  Single access point?

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



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