[pygccxml-development] Loss of typedef in generated code

[Patrick H. <pat...@pr...>]

Using GCC-XML 0.9 and Py++ r1117, I have run into a problem with  
typedefs and portability of generated code with Py++. The basic  
problem is that typedefs used to mask platform-specific type details  
are being discarded in the generated code, and the result is that the  
code is only compiling on the platform where Py++ is run.

A very simple example of the code I am exposing to Python is the  
following:

#if defined(WIN32)
typedef UINT64 myUint64;
#else
typedef uint64_t myUint64;
#endif

class SomeClass
{
public:
    typedef myUint64 id_type;
    typedef std::vector<id_type> id_list_type;

    virtual void f(id_list_type);
};

On a 64-bit Linux installation, Py++ generates code that uses the  
"raw" type std::vector<unsigned long, std::allocator<unsigned long> >  
instead of using either std::vector<myUint64, std::allocator<myUint64>  
 > or, better yet, SomeClass::id_list_type. unsigned long is not the  
same as UINT64 for Windows, nor is it the same as uint64_t on Mac OS X  
(which uses unsigned long long).

I have been tracing through the declarations of the class, member  
function, method arguments, etc., but I cannot find a way to expose  
SomeClass::f() in a way that retains the typedef information. I tried  
inserting replacement registration code, but that does not account for  
the generated SomeClass_wrapper::f() and  
SomeClass_wrapper::default_f() methods having the wrong signature.  
Matters may be complicated further if the method signature were  
changed to be void f(const id_list_type&), but that is not the case at  
the moment.

If nothing else, would updating to a newer version of pygccxml and Py+ 
+ help?

  -Patrick


--
Patrick L. Hartling
Senior Software Engineer, Priority 5
http://www.priority5.com/