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

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.

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

> so I guess we would need const to be part of the function signature
> type.


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



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