pygccxml-development

[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/

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

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

[Roman Y. <rom...@gm...>]

On Dec 17, 2007 10:35 PM, Ben Schleimer <bsc...@lu...> wrote:
> Since gccxml first preprocesses the C++ code before building the AST
> tree, the short answer is probably no.

You right, this is exactly what happens.

> 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.

No, this will not work, because Py++ doesn't support unions. Also
newer version of pygccxml and Py++ will not help in this specific
situation. The latest SVN version contains few improvements in this
area. For example instead of vector< X, std::allocator< X > > Py++ in
many cases will generate vector< X >. I found out, that the definition
of some STL containers is different between GCC and MSVC.

How big is your project? Do you use myUint64 in all your code without
exceptions? If so, I guess it will be safe to run "search and replace"
algorithm on generated code. You can achieve this by "replacing"
code_creator_t.create method (
http://language-binding.net/pyplusplus/documentation/apidocs/pyplusplus.code_creators.code_creator-pysrc.html#code_creator_t.create
)


-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

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

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

On Dec 18, 2007, at 1:24 AM, Roman Yakovenko wrote:

> On Dec 17, 2007 10:35 PM, Ben Schleimer <bsc...@lu...>  
> wrote:
>> Since gccxml first preprocesses the C++ code before building the AST
>> tree, the short answer is probably no.
>
> You right, this is exactly what happens.
>
>> 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.
>
> No, this will not work, because Py++ doesn't support unions. Also
> newer version of pygccxml and Py++ will not help in this specific
> situation. The latest SVN version contains few improvements in this
> area. For example instead of vector< X, std::allocator< X > > Py++ in
> many cases will generate vector< X >. I found out, that the definition
> of some STL containers is different between GCC and MSVC.
>
> How big is your project? Do you use myUint64 in all your code without
> exceptions?

This is the first time that this has cropped up as far as I know. The  
actual type is OSG::UInt64 which comes from OpenSG, a large software  
package upon which ours depends. It is possible that OSG::UInt64 could  
start being used more in the future because our code is using 64-bit  
values as unique identifiers for data objects.

> If so, I guess it will be safe to run "search and replace"
> algorithm on generated code. You can achieve this by "replacing"
> code_creator_t.create method (
> http://language-binding.net/pyplusplus/documentation/apidocs/pyplusplus.code_creators.code_creator-pysrc.html#code_creator_t.create
> )


Thanks for the pointer. I will look into this.

-Patrick


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