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/