Re: [pygccxml-development] Utilizing typedef in code generated by Py++

[Patrick H. <pa...@in...>]

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/