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

David Abrahams wrote:

> Daniel Wallin <[email protected]> writes:
> 
> 
>>David Abrahams wrote:
>>
>>
>>>[Aleksey, please see below w.r.t. lambda exprs]
>>>Daniel Wallin <[email protected]> writes:
>>>
>>>
>>>>David Abrahams wrote:
>>>>
>>>>
>>>>>Daniel Wallin <[email protected]> writes:
>>>>>
>>>Well, this should probably be done for non-member functions as well,
>>>but...
>>>suppose someone does this:
>>>[snip code]
>>>That should show why the most_derived thing is there.
>>
>>OK, I had no idea you could do that. I can see why you would need
>>most_derived there. I'm not sure I can see why anyone would do
>>something like that though, but I haven't given it much thought. :)
> 
> "Like what?"  Did you mean, why anyone would want to use a member
> function on some non-base class as a staticmethod?

Yeah.

> It doesn't really matter; they could be free functions:
> 
> [snip]

OK, I understand.

>>>>How could the converter_tuple_generator know which types should be
>>>>"to" and which should be "from"? 
>>>
>>>If you use a consistent signature ordering as I'm suggesting, it's
>>>easy.  To for the first and from for the rest.
>>
>>Yeah, that would work fine. But I'm not sure I like it. How does it
>>apply to explicit conversions? (object_cast<> / extract<>). I had
>>thought that we'd handle these cases by just supplying a vector1<T>
>>signature sequence.. 
> 
> 
>     vector2<T,object>  // from-XXX
> 
> or 
> 
>     vector2<object,T>  // to-XXX
> 
> Simple ;-)

So we would generate a dummy converter? Hackish. :)

>>But we could tell the policy to generate the converter explicitly
>>instead of using generate_converter_tuple<>.. I'm not sure what I
>>think about this.
> 
> 
> Not sure what you're driving at here.

We could invoke the nested apply<> explicitly instead of applying it 
while iterating over a signature sequence.

   template<class T, class ConverterGenerator>
   T extract(..., ConverterGenerator)
   {
       typename mpl::apply2<
           ConverterGenerator
         , T
         , mpl::int_<0>
       >::type cv;

       return cv.convert(...);
   }

>>>>No I think the children are CallPolicies as well - they should have
>>>>precall/postcall actions.
>>>>
>>>>I'm not sure what you mean by index-agnostic.
>>>
>>>I think I'm just forgetting stuff you already convinced me of, but
>>>what I meant was that the others are only really concerned with
>>>converting a single argument and so don't need an index, while the
>>>CallPolicies are concerned with the whole argument tuple.  But I
>>>think we agreed they all need the index.
>>
>>Yeah I think we did. I guess most of "the others" will likely just
>>ignore the index though, provided that the index is passed to the
>>converter later.
>>
>>    struct my_cv;
>>    my_cv cv;
>>    cv.from(..., mpl::int<2>());
>>
>>vs
>>
>>    template<int N>
>>    struct my_cv;
>>    my_cv<2> cv;
>>    cv.from(...);
> 
> 
> Do we want to pass the index into the converter later?  I don't think
> we do.  Seems to me that you might want some converters to,
> ultimately, work on several indices.  Maybe I'm wrong.

No I think you are right. It's a bit annoying to bind the index in the
converter type though. It does mean we could potentially be subject to
more code bloat since we are using compile time indices.. But I don't
know if there's a way around that, at least not a good one.

>>>>BTW, if you implement the composite CallPolicies like you have in BPL
>>>>there is no reason why offset_arg couldn't store it's Base. That's of
>>>>course a perfectly fine model of CallPolicies as well.
>>>>composite_call_policies is just an example of how it can be done without
>>>>explicit inheritance from your "Base policy".
>>>
>>>I think you can also get there by having the names that the user
>>>handles
>>>    some_policyA(_1)
>>>    ^^^^^^^^^^^^
>>>refer to instances of some concept other than CallPolicies which can
>>>generate CallPolicies.  Not sure what's best yet.
>>
>>I think it's best to allow both approaches.
> 
> 
> It strikes me that the user isn't handling call policy names anyway,
> because,
> 
> 1. In "policyA(_1)", policyA can't be type name.
> 2. policyA(_1) and policyA(_2) have to generate different types.

Right, those are just object generators.

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