The effect of the CLASS_CANNOT_CREATE bit is to set td_init AND td_dealloc to 0 in the generated sipTypeDef. This causes factory methods returning pointers to abstract interfaces to leak memory.
I am going to attempt to patch this, but I still don't know the SIP code very well at all. Anyone know any reason why always generating the dealloc_CLASS function might be a bad idea?
I think I just hadn't considered that case. The next snapshot should be fixed.
I have a small patch. I was going to post it here after I was a little more certain that it will not have any negative side effects. I will post it when I get back to work on Tuesday.
I'd also question why you are using the Abstract annotation. It's only needed
if you are skipping a pure virtual in the .sip file - don't use it if you are
fully specifying the class. I've changed the documentation to try and make
this clearer.
I realized this after being in the sip code for a while. Still using it though, mainly because the interface being wrapped includes accessors for other interfaces I have not yet wrapped. (I would pretty much have to wrap the whole API in one go, and it's not small.)
The other interesting use of the abstract annotation is as a sort of 'final' equivalent in Java. Although I do not expect that anything would complain if I did try to subclass a class wrapped with the Abstract annotation. (This might be a nice feature?) The positive effect is that it will eliminate unnecessary code from the generated pyd file. (Why generate the virtual catchers if the class will never be subclassed from Python?)
James
-- This is not my home; the cats just let me stay here.
_______________________________________________ PyKDE mailing list [email protected] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
