On 10/10/06, Allen Bierbaum <al...@vr...> wrote:
> Roman Yakovenko wrote:
>
> > On 10/10/06, Allen Bierbaum <al...@vr...> wrote:
> >
> >> I just read this document and although it describes what is causing Py++
> >> to generate the code I am not sure it answers the issues I am having:
> >>
> >> 1. Only the last method wrapped is able to be called from python, so why
> >> wrap the others?
> >
> >
> > I don't understand what do you mean by the first one and by the last one.
> > I am able to call all exposed methods
>
> When you have multiple methoded registered with boost.python and they
> only vary by return types, it seems that only the last one "def"'ed
> really gets used.
>
> For example:
>
>
> { //::OSG::GeoVectorProperty::getValue
> typedef ::OSG::Color3f (
> ::OSG::GeoVectorProperty::*getValue_function_type )( ::OSG::UInt32 const
> ) const;
> GeoVectorProperty_exposer.def(
> "getValue"
> , getValue_function_type(
> &::OSG::GeoVectorProperty::getValue )
> , ( ::boost::python::arg("index") ) );
> }
> { //::OSG::GeoVectorProperty::getValue
> typedef ::OSG::Vec3f (
> ::OSG::GeoVectorProperty::*getValue_function_type )( ::OSG::UInt32 const
> ) const;
> GeoVectorProperty_exposer.def(
> "getValue"
> , getValue_function_type(
> &::OSG::GeoVectorProperty::getValue )
> , ( ::boost::python::arg("index") ) );
> }
>
> Maybe I am wrong here, but in this situation there is no way for
> boost.python to select which method to call correct?
>
> As I understand it this is the reason for renaming the methods using the
> aliases is to handle this and allow the user to call any of the methods.
Right
> >> 3. Why do I have to change the function name to demangled name
> >
> >
> > I think that the document explain this. What you did not understand?
> > I will try to improve the document. Even in C++ you have to use
> > x.get_value< y > syntax.
>
> What I am getting at is that all that really matters is the alias. The
> code generated by Py++ (see above) is correct except that all the
> methods are named the same thing so they overwrite each other. I have
> found that if I just change the alias for the method then the generated
> code compiles correctly and accesses the right method.
I think you make a mistake, but it is up to you.
> >
> >> , can't I
> >> just change the alias to what I want the method to appear as and rely
> >> upon Py++ to use casts to get the correct method?
> >
> >
> > No, because you will use C style cast on unrelated types. I don't
> > know whether it will work or not. Anyway this is a wrong way to go.
>
> Don't you just end up with casts that convert the class member pointer
> to the correct signature? It seems to work for me.
struct env_t{
int get_value();
template< class T>
T get_value();
}
I think that env_t::get_value and env_t::get_value<int> have different types.
Casting from one type to another is a mistake. But I could be wrong. You'd
better ask this question on appropriate mailing list
--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/
|