[QGIS-Developer] Is it just me, or is sip totally broken?

[Matthias Kuhn]

Hi Martin

On 07.01.19 13:22, Martin Dobias wrote:
> Hi Matthias
>
> On Mon, Jan 7, 2019 at 12:34 PM Matthias Kuhn <matthias at 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