Re: [PyQt] Possible bug in SIP
> > I can work around the issue here by either (1) redeclaring in sip all > base > > class 'virtual' methods in all the derived classes > > That's not a work around - that's what you are supposed to do, ie. tell > SIP about all the implementations. > Ah - ok, I've been looking at the sip qt wrappings as a model (for obvious reasons) and didn't notice that you had done that for the virtual methods. > > With this particular example you might choose not to wrap getTypeId() > at > all and instead use it to implement %ConvertToSubClassCode. > Yes - I've been using %ConvertToSubClassCode to great effect in other areas. On another note, I've created a pyparsing parser of .sip files because I need to extend SIP somewhat, others users might find it useful - is the wiki a good place to put it? Regards Tony ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Possible bug in SIP
On Tue, 12 Jul 2011 15:52:05 +0100, "Tony Lynch" wrote:
>> >
>> > 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?
No, and not for a while.
> 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
That's not a work around - that's what you are supposed to do, ie. tell
SIP about all the implementations.
> or (2) munge the
> generated wrapper cpp code to call e.g. this->getTypeId() instead of
> A::getTypeId().
That will go recursive.
With this particular example you might choose not to wrap getTypeId() at
all and instead use it to implement %ConvertToSubClassCode.
Phil
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Possible bug in SIP
> >
> > 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 listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Possible bug in SIP
On Mon, 11 Jul 2011 12:12:11 +0100, "Tony Lynch" wrote: > Hi Phil > > > > I'm using SIP to wrap a large C++ library I wonder which one that is... :) > and am very impressed with the > results so far - you've got an annotation for most of the use cases I'm > interested in. However, I think I've found a bug. I've copied in below > my own 'description to self' of the problem, if it is not sufficient for > you to see the problem then I'll knock up a test case (let me know). > > > > When the wrapper for a class or one of its super classes indicates > 'virtual' for a method, a wrapper class is created in SIP called e.g. > sipIwBrep, that checks if the python instance has an override method for > the virtual call. If not then it calls what it thinks is the correct > superclass call. However, it's idea of the correct superclass call (in > this case the superclass being IwBrep) is actually calculated from the > wrapper declarations and it effectively finds the nearest superclass > where the relevant function is wrapped. In the case of this bug, > IwObject was the first superclass to have IsKindOf in the .sip file, so > sipIwBrep was incorrectly calling IwObject::IsKindOf instead of > IwBrep::IsKindOf. > > > > I cannot see any reason why the SIP-produced subclass does not always > call the method on the immediate superclass (i.e. the wrapped class, in > this case IwBrep). > > > > I hope the above makes sense, > > Regards > > Tony The honest reason is, all those years ago when I first wrote the code, I didn't realise that C++ would do the right thing when calling a non-existent explicit super-class method. 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 ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Possible bug in SIP
I think it would help if you could provide a working example of this bug. Like a sip file which reproduces this behavior. On Mon, Jul 11, 2011 at 7:12 AM, Tony Lynch wrote: > Hi Phil > > > > I’m using SIP to wrap a large C++ library and am very impressed with the > results so far – you’ve got an annotation for most of the use cases I’m > interested in. However, I think I’ve found a bug. I’ve copied in below my > own ‘description to self’ of the problem, if it is not sufficient for you to > see the problem then I’ll knock up a test case (let me know). > > > > When the wrapper for a class or one of its super classes indicates > 'virtual' for a method, a wrapper class is created in SIP called e.g. > sipIwBrep, that checks if the python instance has an override method for the > virtual call. If not then it calls what it thinks is the correct superclass > call. However, it's idea of the correct superclass call (in this case the > superclass being IwBrep) is actually calculated from the wrapper > declarations and it effectively finds the nearest superclass where the > relevant function is wrapped. In the case of this bug, IwObject was the > first superclass to have IsKindOf in the .sip file, so sipIwBrep was > incorrectly calling IwObject::IsKindOf instead of IwBrep::IsKindOf. > > > > I cannot see any reason why the SIP-produced subclass does not always call > the method on the immediate superclass (i.e. the wrapped class, in this case > IwBrep). > > > > I hope the above makes sense, > > Regards > > Tony > > ___ > PyQt mailing listPyQt@riverbankcomputing.com > http://www.riverbankcomputing.com/mailman/listinfo/pyqt > ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] Possible bug in SIP
Hi Phil I'm using SIP to wrap a large C++ library and am very impressed with the results so far - you've got an annotation for most of the use cases I'm interested in. However, I think I've found a bug. I've copied in below my own 'description to self' of the problem, if it is not sufficient for you to see the problem then I'll knock up a test case (let me know). When the wrapper for a class or one of its super classes indicates 'virtual' for a method, a wrapper class is created in SIP called e.g. sipIwBrep, that checks if the python instance has an override method for the virtual call. If not then it calls what it thinks is the correct superclass call. However, it's idea of the correct superclass call (in this case the superclass being IwBrep) is actually calculated from the wrapper declarations and it effectively finds the nearest superclass where the relevant function is wrapped. In the case of this bug, IwObject was the first superclass to have IsKindOf in the .sip file, so sipIwBrep was incorrectly calling IwObject::IsKindOf instead of IwBrep::IsKindOf. I cannot see any reason why the SIP-produced subclass does not always call the method on the immediate superclass (i.e. the wrapped class, in this case IwBrep). I hope the above makes sense, Regards Tony ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
