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

Daniel Wallin <[email protected]> writes:

> At 15:42 2003-09-21, David Abrahams wrote:
>>Daniel Wallin <[email protected]> writes:
>>
>> > At 12:47 2003-09-21, David Abrahams wrote:
>> >>Daniel Wallin <[email protected]> writes:
>> >>
>> >> > Does the converter really need access to the whole argument list? I
>> >> > don't see why, at least if we do the "filtering" before passing it
>> >> > into the converter function. I thought this is what you are doing in
>> >> > Boost.Python with the new changes, but I could have misunderstood.
>> >>
>> >>Yes, that's what I'm doing, but it's not ideal.  For example, what
>> >>gets passed to converters for out arguments that don't actually even
>> >>appear in the XXX arguments?  What if you want a converter to combine
>> >>two XXX arguments to produce one C++ argument?  These are the sorts of
>> >>things that are possible with SWIG typemaps but not with Boost.Python.
>> >
>> > Ok, that's kind of cool. So what you are suggesting is that the converter
>> > gets the entire argument package, and the index?
>> >
>> >    c0.convert(argument_package, mpl::int_<1>());
>>
>>Actually I was thinking that the index should be encoded in the type
>>of the converter.
>
> Ok, both approaches work. 

I think we may have single converter tuple at this point.  If so we'll
want something like:

       converters.convert(argument_package,mpl::int_<1>());

> I guess there may be complications in binding the index in the
> converter type. For instance you'd need more information available
> at the time of generating converters. I don't know if it matters
> though.

I want that all to be done before we get to the invocation function;
I don't think it's a huge obstacle.

>> >> > In luabind we do
>> >>
>> >>What precisely do you mean by that?
>> >
>> > I mean we preserve constness in the objects that are held in lua. We have
>> > a bool in our object_rep that tells us if the object is const or
>> not. This is
>> > used in overload resolution.
>>
>>Whoo hoo!  Well, I'll be happy to take that feature; we should just
>>put it in langbinding ;->
>
> :) Ok.. FWIW, the problem with char* is solved with specialization in luabind.

I think we may have a solution by now in Boost.Python as well; I
haven't checked.

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



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