[C++-sig] Boost.python suggestion + pyste bug

[Nicodemus]

Hi Niall,

Niall Douglas wrote:

>Oh Nicodemus! Pyste is generating multiple def()'s with the same name 
>where it doesn't need them. Here's what's happening: if A inherits B 
>which inherits C and each of A, B & C provide a method called 
>"metaClass", then when wrapping A only pyste currently adds a 
>.def("metaClass", &X::metaClass) where X is A,B,C ie; it adds one for 
>B & C too where under C++ inheritance rules B::metaClass() and 
>C::metaClass() disappear. It shouldn't add the B::metaClass() nor 
>C::metaClass().
>
>A similar problem exists where A, B & C all define a class (let's 
>call it FXMapEntry). Once again pyste writes out class definitions 
>for each and every FXMapEntry for each of A, B & C where really it 
>should only do so for A::FXMapEntry.
>
>And lastly, the other similar problem is for enum's. If A, B & C all 
>define an enum where C::ID_LAST is B::ID_FIRST and B::ID_LAST is 
>A::ID_FIRST etc. then pyste defines all the ID_LAST's and ID_FIRST's 
>(and thus causing a runtime error). It should in this case only 
>define those items defined in the most derived class.
>

Ouch! Those were really serious, thanks a lot for the report! I fixed 
them in the CVS, and added a test case that exercices this.

>Speaking of enum's, multiple anonymous enum's (which pyste generates 
>as _enum<int, "unnamed">) cause boost.python to die because it likes 
>every enum's first parameter to be a unique type (couldn't we change 
>this behaviour for simple types?). I worked around this by having 
>pyste specify a "UniqueInt<n>" where n is a globally incremented 
>counter. The definition of UniqueInt is:
>
>template<int num> struct UniqueInt { int v; enum { value=num }; 
>UniqueInt(int _v) : v(_v) { } operator int() const { return v; } };
>  
>

Hmm, thanks again for reporting this. I'll fix this as soon as possible.

>Lastly, am I right in thinking that pyste currently does not use 
>boost.python's ability to represent C++ class inheritance trees the 
>same in python classes? I'm thinking that if you were to add support 
>for this, it kinda works with the fixes necessary for fixing the bugs 
>above.
>

What do you mean? It should export classes in the same way as if you 
were doing it by hand, but automatically. One difference is that it now 
automatically exports the members of base classes that were not exported 
themselves, as a feature request here in the list:

struct A
{
    void foo();
};

struct B: A
{
    void bar();
};

If you export only B, you will get A's foo method too, as if you were 
exporting both A and B.

Regards,
Nicodemus.