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
