> >
> > I'm using SIP to wrap a large C++ library
>
> I wonder which one that is... :)
You guessed it :-). I have to say that SIP is helping greatly in the wrapping
process and I'm genuinely impressed at how much functionality it's bringing.
> So it's not a bug, it's a
> conscious decision to do it that way. "Fixing" it would be a change of
> behaviour which I'm not willing to do for SIP4 - happy to change it for
> SIP5 though.
>
> Phil
I don't know where you are with SIP5 - is there a nightly build I can download?
This issue has a real impact on the code I am working with (actually, it
crashes because of it). I've made a simple test project to demonstrate the
issue because I think for us it means that using SIP's 'virtual' mechanism and
SIP's inheritance mechanism become mutually incompatible. I'm sending you
direct a tar file of the code, in a nutshell it is:
3 classes, C inherits B inherits A.
int A::getTypeId() {
return 1;
};
int B::getTypeId() {
return 2;
};
int C::getTypeId() {
return 3;
};
In the sip files getTypeId() is only listed for A, and B and C pick it up via
SIP's inheritance mechanism. If getTypeId() is not declared as virtual in the
sip file then the following python code passes:
from ABC import C
assert(C().getTypeId() == 3)
However, if I declare the method as virtual in the sip file then the python
test fails (1 is returned).
I can work around the issue here by either (1) redeclaring in sip all base
class 'virtual' methods in all the derived classes or (2) munge the generated
wrapper cpp code to call e.g. this->getTypeId() instead of A::getTypeId().
Regards
Tony
_______________________________________________
PyQt mailing list [email protected]
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
