Hi Martin
On 07.01.19 13:22, Martin Dobias wrote:
Hi Matthias
On Mon, Jan 7, 2019 at 12:34 PM Matthias Kuhn <matth...@opengis.ch> wrote:
Are you convinced that the proper solution will be a /ReleaseReference/
annotation?
I am not convinced, but for now I do not have a better idea :-)
I agree that the virtual destructors could automatically release that
held reference, so /ReleaseReference/ would only be needed in cases
like take() method where the object is not being deleted, but c++
should not hold the reference anymore.
even in these cases I am hoping for an automated version for anything
that is annotated with /TransferBack/.
I would assume that the current information is sufficient for sip /
sipify to generate proper bindings without a new annotation.
From what I understand, sip creates an internal subclass that forwards
virtual methods to their python implementations. I would assume that the
destructor of this subclass can be used to trigger the garbage
collection / decreasing the ref counter and the reference counter should
be increased when the object is sent through a /Transfer/ annotated
function parameter.
I am not sure if /Transfer/ should automatically increase reference
counter. It would add unnecessary extra memory footprint when not
passing a derived object (if you just want to pass some simple data
objects) - in such case it is not useful to keep python references
around if they will never be used again in Python code. But this is
probably best to discuss with Phil as I am by no means a SIP expert
and there are maybe other issues that we are not aware of.
This would only work in cases where the destructor of the parent class
is virtual anyway. For other scenarios the garbage collection cannot be
automated (at least not without a /ReleaseReference/ annotation or some
other magic I'm not aware of right now). For classes which already have
a vtable it could be considered acceptable to have a slightly increased
footprint if created in Python to ensure that the C++ part holds a
reference to the corresponding Python part after a /Transfer/ operation.
Anyway, contacting Phil is certainly a good idea.
Cheers
Matthias
Cheers
Martin
_______________________________________________
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
