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

David Abrahams wrote:
> Daniel Wallin <[email protected]> writes:
> 
>>Because the different CallPolicies in the composite_call_policies type
>>have no knowledge of each other. 
> 
> 
> What I don't like here is the need for a "special overload".  It feels
> like a very nonuniform special-case.  And it proliferates: you'll need
> to do something similar for arity (querying the size of the argument
> package), won't you?

Yes. It could be written:

    template<class Base, int M, int M>
    PyObject* get(
        const composite_package<offset_arg<N>, Base>& args
      , mpl::int_<N>)
    {
        return get(args.base(), mpl::int_<N + M>());
    }

Althought that's probably more characters to type. ;)

>>Meaning we would need to make the
>>nested argument_package a metafunction:
>>
>>   struct my_policy
>>   {
>>       template<class Base>
>>       struct argument_package
>>       {
>>           typedef offset_arg<1, Base> type;
>>       };
>>   };
> 
> 
> That might be better.

I disagree. Earlier I agreed with you that it was better to consider
CallPolicies as one concept and doing the actual composing (?) at
another level. To me, having a metafunction implies that there are
actually other CallPolicies as well. Which seems to contradict our
there-is-only-one design somewhat.

With the interface I proposed there is no such implication. You only
need the special overload if you are using composite_call_policies. In
another implementation that uses explicit inheritance (like BPL), you
won't need the overloads.

>>I think it's nicer to create a composite hierarchy:
>>
>>   composite_argument_package<
>>       offset_arg<1>
>>     , composite_argument_package<
>>           offset_arg<9>
>>         , composite_argument_package_native<
>>               PyObject*
>>           >
>>       >
>>   >
>>
>>   template<class Pkg, class Base>
>>   struct composite_argument_package : Base
>>   {
>>       // some forwarding constructors goes here
> 
> 
> Nasty.  Forwarding is hard to do well.

Not in this case. Every argument_package must be constructible from the
native argument package, so there is no forwarding problems here. Not
that I can see anyway.

>>       Pkg pkg_;
>>   };
>>
>>   template<class Pkg, class Base, int N>
>>   PyObject* get(
>>       const composite_argument_package<Pkg, Base>& x, mpl::int_<N>)
>>   {
>>       // forward to correct get() function
>>       return get(x.pkg_, static_cast<const Base&>(x), mpl::int_<N>());
> 
> 
> Why are you using static_cast instead of implicit_cast here?

No reason, I'm just not used to implicit_cast. :)

-- 
Daniel Wallin



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