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

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

> >> >>Anything I'm missing?  Your thoughts?
> >> >
> >> > No I think that about covers it. The current implementation (in
> >> > luabind, and some of langbinding..) doesn't use tag-dispatching for
> >> > the invoke functions, but I guess there are reasons that
> >> > tag-dispatch is better than class specialization here.
> >> >
> >> > BTW, does Boost.Python handle const functions/objects?
> >>
> >>There's no notion of const objects in Python, so although we do
> >>"handle" const member functions and objects, we don't do anything
> >>special for them.  There is a notion of immutability which applies to
> >>*types* (not objects), and I've thought about how that could be
> >>handled: http://mail.python.org/pipermail/c++-sig/2002-May/001023.html
> >>but haven't implemented anything.
> >>
> >> > 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.

---
Daniel Wallin



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