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

At 18:53 2003-09-21, David Abrahams wrote:
>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 have expressed some concern on this before due to the issue with an
additional layer when returning temporaries from convert().
(with const& argument types..)

I would rather see something like:

    get<0>(converters).convert(argument_package);

or

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

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

Agreed.

---
Daniel Wallin



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