[pygccxml-development] Loss of typedef in generated code
Brought to you by:
mbaas,
roman_yakovenko
|
From: Patrick H. <pat...@pr...> - 2007-12-17 16:22:01
|
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/
|