[PyQt] Classes with private destructors get subclassed by SIP

[Shaheed Haque]

On 16 June 2017 at 10:41, Phil Thompson <phil at riverbankcomputing.com> wrote:
> On 13 Jun 2017, at 5:44 pm, Shaheed Haque <srhaque at theiet.org> wrote:
>>
>> Hi,
>>
>> Given a SIP class like this (c.f. KF5/KIOWidgets/kautomount.h):
>>
>> =====================
>> class PrivateDestructor
>> {
>> public:
>>    PrivateDestructor() {};
>> private:
>>    virtual ~PrivateDestructor() {};
>> private:
>>    PrivateDestructor(const PrivateDestructor &) {};
>> };
>> =====================
>>
>> SIP ends up creating a subclass which, if I am reading StackOverflow
>> correclty, is not allowed because of the private destructor. That
>> inevitably leads to errors from the compiler like this:
>>
>> =====================
>> In file included from unifiedPySample.cpp:1:0:
>> /tmp/tmpwxNqBS/tmp2/tmp/PySample/sipPySamplePrivateDestructor.cpp:48:7:
>> error: deleted function ‘virtual
>> sipPrivateDestructor::~sipPrivateDestructor()’
>> class sipPrivateDestructor : public  ::PrivateDestructor
>>       ^~~~~~~~~~~~~~~~~~~~
>> In file included from /tmp/tmpwxNqBS/tmp2/sip/PySample/sample1.sip:26:0,
>>                 from sipPySamplePrivateDestructor.cpp:40,
>>                 from unifiedPySample.cpp:1:
>> /mnt/main/srhaque/NFS/kdedev/frameworks-bindings/extra-cmake-modules/find-modules/module_generation/tests/sources/sample1.h:102:13:
>> error: overriding non-deleted function ‘virtual
>> PrivateDestructor::~PrivateDestructor()’
>>     virtual ~PrivateDestructor() {};
>>             ^
>> =====================
>>
>> and so on and so on. Perhaps the logic for triggering a subclass needs
>> to exclude this case?
>
> I can't recreate this with the current snapshot.

Yes, this is now working as expected with sip-4.19.3.dev1706161918.

>> Thanks, Shaheed
>>
>> P.S. On a separate-but-related matter, if this area of the code is
>> indeed the area that needs to be modified, for the case where SIP
>> determines that a subclass is NOT required, it would be really handy
>> for me if SIP were to provide a macro like this:
>>
>> #define sipPrivateDestructor PrivateDestructor
>>
>> The point being that my machine-generated "hand-written" code can be
>> written in terms of sipPrivateDestructor, whereas now, in every such
>> case, I have to add the #define from custom logic.
>
> I don't want to add things for an individual use case that I then have to support for ever.

OK, thanks for considering it.

> Phil
>