Re: [pygccxml-development] Utilizing typedef in code generated by Py++
Brought to you by:
mbaas,
roman_yakovenko
From: Patrick H. <pa...@in...> - 2007-05-10 22:34:03
|
Roman Yakovenko wrote: > On 5/10/07, Patrick Hartling <pa...@in...> wrote: >> I have run into a case where a typedef used for portability varies in = the >> actual type in use. The type being defined is GLenum from OpenGL. On >> Linux >> and Windows, the underlying type for GLenum is unsigned int, but on >> Mac OS >> X, it is unsigned long. When Py++ generates the Boost.Python bindings >> code >> for functions that include GLenum in their signature, it uses the >> underlying >> type in the function signature typedef rather than GLenum. This >> results in >> compile failures when generating the code on Linux and trying to >> compile on >> Mac OS X (or vice versa). >> >> In trying to resolve this, I have come up with two questions: >> >> 1. Can Py++ generate code that uses typedefs instead of fully expan= ded >> types? >=20 > Right now it cannot, but it is possible to implement this feature. > Also you should understand that the user will have to say when Py++ > should use a typedef or real type. OK. I was trying to find some flag to set or something since I expected t= his to be something that the user would have to do. This could be a very usef= ul feature to have in the future, especially for the case of typedefs being used to make code more portable. Losing that thin layer of abstraction ca= n lead to problems. >> 2. Is there a way to have a special case where GLenum can be used >> in the >> generated code and everything else can continue using fully >> expanded >> types? >=20 > Yes. There are so many ways to implement this in Py++. I don't know > the exact use case, so I will give you all possible solutions: >=20 > 1. You can ask Py++ to generate your code instead of the default one: > =20 > http://www.language-binding.net/pyplusplus/documentation/inserting_code= =2Ehtml >=20 >=20 > Not the best one >=20 > 2. Lets say you have function argument or member variable with such > fully expanded type and you want Py++ to generate typedef - you can > just replace the type of the variable: >=20 > from pygccxml import declarations >=20 > mb =3D module_builder_t( ... ) > f =3D mb.member_function( 'f' ) > #lets say that you want to replace second argument > f.arguments[1].type =3D declarations.dummy_type_t( 'GLenum' ) >=20 > dummy_type_t documentation > http://www.language-binding.net/pygccxml/apidocs/pygccxml.declarations.= cpptypes.dummy_type_t-class.html >=20 >=20 > If you give some concrete example, may be I will be able to provide > better answer. The case I have to deal with at the moment involves the return type of a member function. The return type is a template class for std::vector-like= object that takes a template parameter specifying the contained data type= =2E In the C++ code, a member function will look like this: const OSG::MFGLenum& getValue() const; OSG::MFGLenum is a typedef for OSG::MField<GLenum,1> (the 1 is for intern= al usage, I think), and GLenum is in turn a typedef. On Linux, the bindings code that gets generated uses OSG::MField<unsigned= ,1> as the return type, and that is where the problem arises. There is alread= y some code being inserted to convert these OSG::MField<> instantiations in= to boost::python::list, and it turns out that this bit of code is explicitly= discarding the typedef information as part of stripping the return type d= own to its "naked" form. Using the original information for the member functi= on return type, I have added what is needed for this case. It is not elegant= , but it works [*]. >> The second question came to mind because this currently affects only t= wo >> .cpp files out of over 350 being generated by Py++. >=20 > :-) Be sure to read the first link I gave to the end. It is possible > to configure Py++ to generate code which will contain only bare > minimum of included files. This is certainly an issue for this particular software, but we're pinnin= g our hopes on using pre-compiled headers in GCC 4.2. We will see how that turns out. Thanks for the help. -Patrick [*] In looking at things more closely, I think I found an opportunity for= a small performance improvement in the generated code that will also elimin= ate the need for treating GLenum as a special case. There will probably be la= ter instances of needing to handle GLenum, though, so it is good to get start= ed on this with something that is relatively easy. --=20 Patrick L. Hartling VP Engineering, Infiscape Corp. http://www.infiscape.com/ |