[C++-sig] Custodian and Ward doubts

[Niall Douglas]

On 12 Sep 2005 at 20:58, Eric Jardim wrote:

> > Of course, if you prefer to
> > keeping banging along alone without examining existing
> > implementations, please do feel free - but don't expect much help
> > from anyone in here.
> 
> Please, don't be so rude. You are being very unfair with me. I am
> doing my best to do this Qt bindings (sorry for being a bad hacker).
> I, in fact, looked at your code. I just did't find what I wanted. I
> just found some converters. I may look again to find something.

Yeah I'm sorry about how I wrote that - it popped into my head last 
night when I was in bed that I was being too harsh. I apologise.

You're actually a *good* hacker, you have got your BPL bindings of Qt 
up to a level which took me far longer with TnFOX. And you've had far 
less questions than I had during the process. So you're doing very 
well.

However, to answer your question, what you need is a mechanism that 
when a Qt object dies, it upcalls to its BPL equivalent that it is 
dead now so the BPL equivalent can mark itself as useless. You can't 
delete the BPL equivalent because python maintains exclusive rights 
to do that, but you must make sure that when python does delete it it 
doesn't go trying to redelete your Qt object.

The way I handled this in TnFOX is to add a special virtual method to 
FXObject which detaches that FXObject instance from its BPL 
representation - if it has one. I then patched pyste to add an 
override for that virtual function to the generated virtual class 
wrapper which does the appropriate detaching. Obviously, non-BPL 
represented FXObject's don't do any detaching.

For Qt, you are slightly more stuck than I was here as you can't just 
go and add a special virtual function to QObject or maybe even the 
MOC (though if you were to ask Trolltech, they might just do so). You 
need some non-intrusive method.

All QObject's will have a virtual destructor, so perhaps in the 
wrapper you could detach from BPL there. I did try this in TnFOX, but 
I ran into problems I think because BPL thinks by then you're getting 
deleted so it's too late - I vaguely remember that the virtual 
function table had got reset by then, implying some class internally 
inherits again from the wrapper. I didn't persist with this solution 
though because having each FXObject make its python representation 
available to all TnFOX code was too attractive, and I have full 
control over the source, so I just went ahead and did that instead.

I hope this helps. BTW, use TnFOX from SVN rather than v0.85 - it has 
many python problems fixed.

Cheers,
Niall