Hi Frank, SWIG already implements this feature: the thisown flag is set to True is the wrapped object owns the underlying C++ instance (see http://www.swig.org/Doc2.0/SWIGPlus.html). In this case, deleting the python object calls the C++ destructor. The flag 'thisown' is defined for one class. The problem is that the byref issue is not class related but method related: some method may return references, other values. So the problem is much more difficult: *if* a method returning a reference is called, then the thisown flag should be set to false (pythonOCC GC then choose the best way to free memory), otherwise the python and C++ objects can be deleted at the same time.
Thomas 2011/5/16 Frank Conradie <fr...@qfin.net> > Hi Thomas > > Regarding this "process_by_ref_argument" workaround, I was wondering if a > different approach might work better: > > Instead of changing "pass by ref" to "pass by value" (thereby also adding > an object copy on the C++ side), what about rather adding an attribute to > the Python wrapper objects which indicates if the underlying OCC object is a > "reference" or a "value", i.e. whether the wrapper "owns" the underlying OCC > object. > > The GarbageCollector can then check this attribute to determine if > _kill_pointed should be called or not when a wrapper goes out of scope, e.g. > something like this: > > misc = self._misc.pop() > if getattr(misc, '_is_ref', False): > misc._kill_pointed() > misc.was_purged = True > > Sorry if this has already been considered and rejected - these are just > some very superficial thoughts about this issue. > > - Frank > > > On 16/05/2011 12:01 PM, Frank Conradie wrote: > >> Hi Thomas >> >> I recently ran into a crash when calling the GarbageCollector smart_purge >> method, and finally figured out that it was because of TopTools_XX >> references returned by some TopTools_XX classes, for which _kill_pointed() >> should of course *not* be called. The specific class/method I was using was: >> >> TopTools_IndexedDataMapOfShapeListOfShape: >> const TopTools_ListOfShape & FindFromIndex (const Standard_Integer I) >> const >> >> I suspect other TopTools classes might suffer from the same issue. Should >> these "TopTools_XX &" returned references be handled using the same special >> case handling as "gp" and "TopoDS" returned references (in >> ModularBuilder.process_by_ref_argument)? >> >> Thanks, >> Frank Conradie >> >> _______________________________________________ >> Pythonocc-users mailing list >> Pythonocc-users@gna.org >> https://mail.gna.org/listinfo/pythonocc-users >> >> > _______________________________________________ > Pythonocc-users mailing list > Pythonocc-users@gna.org > https://mail.gna.org/listinfo/pythonocc-users >
_______________________________________________ Pythonocc-users mailing list Pythonocc-users@gna.org https://mail.gna.org/listinfo/pythonocc-users
