Re: [pygccxml-development] Loss of typedef in generated code

[Ben S. <bsc...@lu...>]

Since gccxml first preprocesses the C++ code before building the AST
tree, the short answer is probably no.
However, I imagine if you did something clever like:
union myUint64 {
#if defined(WIN32)
UINT64 val;
#else
Uint64_t val;
#endif
};

You might be able to save your typing info.

Just a guess
Ben

> -----Original Message-----
> From: pyg...@li...=20
> [mailto:pyg...@li...]=20
> On Behalf Of Patrick Hartling
> Sent: Monday, December 17, 2007 8:21 AM
> To: pyg...@li...
> Subject: [pygccxml-development] Loss of typedef in generated code
>=20
> Using GCC-XML 0.9 and Py++ r1117, I have run into a problem=20
> with typedefs and portability of generated code with Py++.=20
> The basic problem is that typedefs used to mask=20
> platform-specific type details are being discarded in the=20
> generated code, and the result is that the code is only=20
> compiling on the platform where Py++ is run.
>=20
> A very simple example of the code I am exposing to Python is the
> following:
>=20
> #if defined(WIN32)
> typedef UINT64 myUint64;
> #else
> typedef uint64_t myUint64;
> #endif
>=20
> class SomeClass
> {
> public:
>     typedef myUint64 id_type;
>     typedef std::vector<id_type> id_list_type;
>=20
>     virtual void f(id_list_type);
> };
>=20
> On a 64-bit Linux installation, Py++ generates code that uses=20
> the "raw" type std::vector<unsigned long,=20
> std::allocator<unsigned long> > instead of using either=20
> std::vector<myUint64, std::allocator<myUint64>  > or, better=20
> yet, SomeClass::id_list_type. unsigned long is not the same=20
> as UINT64 for Windows, nor is it the same as uint64_t on Mac=20
> OS X (which uses unsigned long long).
>=20
> I have been tracing through the declarations of the class,=20
> member function, method arguments, etc., but I cannot find a=20
> way to expose
> SomeClass::f() in a way that retains the typedef information.=20
> I tried inserting replacement registration code, but that=20
> does not account for the generated SomeClass_wrapper::f() and
> SomeClass_wrapper::default_f() methods having the wrong signature. =20
> Matters may be complicated further if the method signature=20
> were changed to be void f(const id_list_type&), but that is=20
> not the case at the moment.
>=20
> If nothing else, would updating to a newer version of=20
> pygccxml and Py+=20
> + help?
>=20
>   -Patrick
>=20
>=20
> --
> Patrick L. Hartling
> Senior Software Engineer, Priority 5
> http://www.priority5.com/
>=20
>=20