|
From: Roman Y. <rom...@gm...> - 2006-10-10 07:46:03
|
On 10/10/06, Allen Bierbaum <al...@vr...> wrote: > Okay, so my problem is that I am wrapping a class you can see here: I just commited the answer to your question. Take a look on how_to.rest document, last question: How to deal with template on return type functions? > PS. I just tried the latest svn version of Py++ on my largest project > and things seem to be working fine. Can you provide feedback on add_properties algorithms? The documentation in properties.rest document? Also can you read and correct the documentation the project has? Thank you. -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
|
From: Allen B. <al...@vr...> - 2006-10-10 14:50:57
|
Roman Yakovenko wrote: >On 10/10/06, Allen Bierbaum <al...@vr...> wrote: > > >>Okay, so my problem is that I am wrapping a class you can see here: >> >> > >I just commited the answer to your question. Take a look on >how_to.rest document, >last question: How to deal with template on return type functions? > > > 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? 2. I think I see what you are getting at in the solution section about renaming the methods automatically, but this only exposes the ones that are called in the header files that gccxml is compiling. In my case (and I think probably in most cases where this will come up), I want to create "get_value" methods for many more types then gccxml actually saw. Is there any way to know of to force these methods to be instantiated similar to what we do with class templates? 3. Why do I have to change the function name to demangled name, 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? (at least with gcc 4 I get compiler errors trying to do the equivalent of your correct code and get "&::environment_t::get_value<std::string>". -Allen >>PS. I just tried the latest svn version of Py++ on my largest project >>and things seem to be working fine. >> >> > >Can you provide feedback on add_properties algorithms? The >documentation in properties.rest > document? > >Also can you read and correct the documentation the project has? > >Thank you. > > > |
|
From: Roman Y. <rom...@gm...> - 2006-10-10 19:39:58
|
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 > 2. I think I see what you are getting at in the solution section about > renaming the methods automatically, but this only exposes the ones that > are called in the header files that gccxml is compiling. The better way to say this: this is exposes only method that were instantiated. > In my case > (and I think probably in most cases where this will come up), I want to > create "get_value" methods for many more types then gccxml actually > saw. Is there any way to know of to force these methods to be > instantiated similar to what we do with class templates? Just use similar technique and it will work. You also can add code for every instantiated class cls.add_declaration_code( '"get_value_x", &environment_t::get_value< x >' ) > 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. >, 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. > (at least with gcc 4 > I get compiler errors trying to do the equivalent of your correct code > and get "&::environment_t::get_value<std::string>". Just committed the unit test and all works as expected. I am using gcc 4.0.3. What is the error you get? -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
|
From: Allen B. <al...@vr...> - 2006-10-10 20:00:50
|
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.
>> 2. I think I see what you are getting at in the solution section about
>> renaming the methods automatically, but this only exposes the ones that
>> are called in the header files that gccxml is compiling.
>
>
> The better way to say this: this is exposes only method that were
> instantiated.
True.
>> In my case
>> (and I think probably in most cases where this will come up), I want to
>> create "get_value" methods for many more types then gccxml actually
>> saw. Is there any way to know of to force these methods to be
>> instantiated similar to what we do with class templates?
>
>
> Just use similar technique and it will work. You also can add code for
> every
> instantiated class
>
> cls.add_declaration_code( '"get_value_x", &environment_t::get_value< x
> >' )
This seems to have the wrong number of arguments here but I think I know
what you are getting at.
>
>> 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.
>
>> , 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.
>
>> (at least with gcc 4
>> I get compiler errors trying to do the equivalent of your correct code
>> and get "&::environment_t::get_value<std::string>".
>
>
> Just committed the unit test and all works as expected. I am using
> gcc 4.0.3. What is the error you get?
I will need to give it a try and find out the exact problem I was
having. It very well could have been specific to my usage.
-Allen
|
|
From: Roman Y. <rom...@gm...> - 2006-10-10 20:12:27
|
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/
|
