pygccxml-development

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

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

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 Linu=
x
and Windows, the underlying type for GLenum is unsigned int, but on Mac O=
S
X, it is unsigned long. When Py++ generates the Boost.Python bindings cod=
e
for functions that include GLenum in their signature, it uses the underly=
ing
type in the function signature typedef rather than GLenum. This results i=
n
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 expanded=

      types?
   2. Is there a way to have a special case where GLenum can be used in t=
he
      generated code and everything else can continue using fully expande=
d
      types?

The second question came to mind because this currently affects only two
=2Ecpp files out of over 350 being generated by Py++.

Thanks in advance.

 -Patrick


--=20
Patrick L. Hartling
VP Engineering, Infiscape Corp.
http://www.infiscape.com/

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

[Roman Y. <rom...@gm...>]

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 expanded
>       types?

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.

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

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:

1. You can ask Py++ to generate your code instead of the default one:
    http://www.language-binding.net/pyplusplus/documentation/inserting_code.html

    Not the best one

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:

from pygccxml import declarations

mb = module_builder_t( ... )
f = mb.member_function( 'f' )
#lets say that you want to replace second argument
f.arguments[1].type = declarations.dummy_type_t( 'GLenum' )

dummy_type_t documentation
http://www.language-binding.net/pygccxml/apidocs/pygccxml.declarations.cpptypes.dummy_type_t-class.html

If you give some concrete example, may be I will be able to provide
better answer.

> The second question came to mind because this currently affects only two
> .cpp files out of over 350 being generated by Py++.

:-) 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.

HTH

-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

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/

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

[Roman Y. <rom...@gm...>]

On 5/11/07, Patrick Hartling <pa...@in...> wrote:
> 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.
> 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
internal
> usage, I think), and GLenum is in turn a typedef.

Ok, now I can provide better answer.

Py++ has nice feature related to "class typedefs"
http://www.language-binding.net/pyplusplus/documentation/hints.html

Py++ do knows all typedefs related to the class, but uses them only for
aliasing - name of the class for Python user. I think it can use them for
"class registration" too and thus to achieve better portability. Thanks for
this idea.

Can you submit "feature request"(
http://sourceforge.net/tracker/?group_id=118209&atid=684321 )?

> 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 already
> some code being inserted to convert these OSG::MField<> instantiations
into
> 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
down
> to its "naked" form. Using the original information for the member
function
> return type, I have added what is needed for this case. It is not elegant,
> but it works [*].

I lost you :-(

> > :-) 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 pinning
> our hopes on using pre-compiled headers in GCC 4.2. We will see how that
> turns out.

May be you should consider distributed compilation too.

>
> [*] In looking at things more closely, I think I found an opportunity for
a
> small performance improvement in the generated code that will also
eliminate
> the need for treating GLenum as a special case. There will probably be
later
> instances of needing to handle GLenum, though, so it is good to get
started
> on this with something that is relatively easy.

Do you mean that Py++ can generate better code in some cases? If so I would
like to know these use-cases and tweak it.

-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

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

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

Roman Yakovenko wrote:
> On 5/11/07, Patrick Hartling <pa...@in...
> <mailto:pa...@in...>> wrote:
>> 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-l=
ike
>> object that takes a template parameter specifying the contained data t=
ype.
>> 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
> internal
>> usage, I think), and GLenum is in turn a typedef.
>=20
> Ok, now I can provide better answer.
>=20
> Py++ has nice feature related to "class typedefs"
> http://www.language-binding.net/pyplusplus/documentation/hints.html
>=20
> Py++ do knows all typedefs related to the class, but uses them only for=

> aliasing - name of the class for Python user. I think it can use them
> for "class registration" too and thus to achieve better portability.
> Thanks for this idea.
>=20
> Can you submit "feature request"(
> http://sourceforge.net/tracker/?group_id=3D118209&atid=3D684321
> <http://sourceforge.net/tracker/?group_id=3D118209&atid=3D684321> )?

Certainly. I will do it as soon as I can.

>> 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 alr=
eady
>> some code being inserted to convert these OSG::MField<> instantiations=

> into
>> boost::python::list, and it turns out that this bit of code is explici=
tly
>> discarding the typedef information as part of stripping the return
> type down
>> to its "naked" form. Using the original information for the member
> function
>> return type, I have added what is needed for this case. It is not
> elegant,
>> but it works [*].
>=20
> I lost you :-(

Don't worry about it. I was just "thinking out loud" about how I could de=
al
with the case that I have.

>> > :-) 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 pin=
ning
>> our hopes on using pre-compiled headers in GCC 4.2. We will see how th=
at
>> turns out.
>=20
> May be you should consider distributed compilation too.

That is already being done to some extent. I am not doing it, but that is=

mainly because I have enough other things to do that I can let builds run=

for a while and then come back to test things when it finishes. It also
doesn't help that I am using operating environments that are not availabl=
e
beyond the door to my office.

>> [*] In looking at things more closely, I think I found an opportunity
> for a
>> small performance improvement in the generated code that will also
> eliminate
>> the need for treating GLenum as a special case. There will probably be=

> later
>> instances of needing to handle GLenum, though, so it is good to get
> started
>> on this with something that is relatively easy.
>=20
> Do you mean that Py++ can generate better code in some cases? If so I
> would like to know these use-cases and tweak it.

It is generating what I consider to be better code by making use of
information provided by Py++. It is specific to this usage of Py++ becaus=
e
we are injecting custom code to handle this one type conversion.

 -Patrick


--=20
Patrick L. Hartling
VP Engineering, Infiscape Corp.
http://www.infiscape.com/