I gave up on reference counting as the existing swig support wasn't doing what we needed by itself. Getting things working right would not be too hard technically, but would take a bit of time and perhaps per- class entries in IMP.i.
Here is what I posted to the swig list. The only responses I got were "Yeah, that would be nice"
I would like to have reference counted objects that work across C++ and Python both for objects which are purely C++ objects and Python objects which inherit from C++ base classes. This seems relatively easily to implement by: - Purely C++ objects or python objects extending C++ objects which don't have virtual functions are just treated like they currently are-- their reference count is incremented if there is a python reference to them and decremented if there is no python reference. If the python proxy object goes away before the C++ object, it is fine. The C++ object can't go away without all python references being destroyed. - With Python objects which inherit from C++ objects with virtual functions, swig has to keep the python proxy object alive until the C++ object is destroyed. This can be done by internally keeping a reference to the python object until the C++ object is destroyed. Then the director can use the call to the virtual C++ destructor (which needs to be there on the C++ side anyway) to remove the reference to the python object so that it too goes away.
While it is straight forward, I don't see any way to easily turn on or provide this functionality for a large array of classes. I am quite new to SWIG so I might be missing something. Any suggestions or alternatives? Thanks.
On Dec 14, 2007, at 5:14 PM, Ben Webb wrote:
> Daniel Russel wrote: >> DistanceRestraint now takes a pair of ParticleIndexes and a ScoreFunc >> which it then owns. > > On this subject, did you make any more progress with the reference > counting code? It seems like this would be a obvious candidate for > reference counting (e.g. an excluded volume may create thousands of > distance restraints, all of which share a single scoring function by > increasing its reference count). I seem to recall that you were > stuck at > the Python interface. If this is still the case, I can take a look, > as I > (probably) know a bit about the SWIG internals. > > If others think reference counting of IMP objects is a bad idea, now's > the time to say... > > Ben > -- > ben@salilab.org http://salilab.org/~ben/ > "It is a capital mistake to theorize before one has data." > - Sir Arthur Conan Doyle > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev