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/