On 5/11/07, Patrick Hartling <firstname.lastname@example.org> 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"
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.
C++ Python language binding