Re: Conversion policies

Daniel Wallin <[email protected]> writes:

> At 23:40 2003-08-07, David Abrahams wrote:
>>Daniel Wallin <[email protected]> writes:
>>
>> > At 14:51 2003-08-05, David Abrahams wrote:
>> >>Daniel Wallin <[email protected]> writes:
>> >>
>> >> > I've checked in a basic framework for conversion policies, like the
>> >> > one we have in luabind.
>> >> >
>> >> >    boost/langbinding/policy.hpp
>> >>
>> >>Q1: Why use a handbuilt cons-list in lieu of mpl::list?
>> >
>> > Because I want to overload operator+ to compose the list. Also I want to
>> > be able to have data in the policies.
>>
>>Oh, sounds like a tuple.
>
> Yeah, it is.
>
>> >>Q2: Conversion policies may carry data in them; it seems to me that
>> >>     you need a runtime identification mechanism.  How about CRTP?
>> >
>> > Elaborate, where does CRTP apply here?
>>
>>Never mind; I misinterpreted your code.  I think it's finally dawning
>>on me what it's intended to do... but a realistic usage example would
>>be a huge help.
>
> OK. Sorry for being vague. I'll try with some short examples:
>
> This is the policy system which handles the converter generators and
> precall/postcall. Consider a typical invoke-function:
>
> template<class R, class A0, class A1, class Policies>
> ret_type invoke(R(*fn)(A0, A1), const Policies& policies)
> {
>     // find the converter generators for the given parameter index
>     typedef typename find_conversion_policy<1, Policies>::type conversion_gen1;
>     typedef typename find_conversion_policy<2, Policies>::type conversion_gen2;
>
>     // generate a converter for the associated type
>     typename conversion_gen1::template generate_converter<A0,
>     xxx_to_cpp>::type c1;
>     typename conversion_gen2::template generate_converter<A1,
>     xxx_to_cpp>::type c2;
>
>     // the converter objects are later applied to the parameter passed from the
>     // interpreter state to get the actual parameters.
> }

OK, I understand now.

here's what I was thinking might make for a more efficient
implementation.  Instead of using all of that TMP inside of every
wrapped function implementation, arrange the policies type so that it
can do all the work with overloading:

template<class R, class A0, class A1, class Policies>
ret_type invoke(R(*fn)(A0, A1), const Policies& policies, ArgTuple t)
{
    if !(
         policies.check(_1, identity<A0>(), t[0])
       , policies.check(_2, identity<A1>(), t[1])
    )
    return kOverloadFailed;
        
    return policies.from_cxx(
        fn(
             policies.to_cxx(_1, identity<A0>(), t[0])
           , policies.to_cxx(_2, identity<A1>(), t[1])
        )
    );
}

Just a thought.

> The purpose of the xxx_to_cpp/cpp_to_xxx types is to have converter generators
> that can generate converters for both directions.

OK.

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



-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01