[Interest] sharing singleton instance between C++ and QML

[Mike Trahearn]

Thanks Ulf.

QTBUG-116432 wasn't the thing I'd alluded to, actually it was something I came across with some older code which had also the use of Q_GLOBAL_STATIC which demands public ctors. The QML engine did not call the supplied create function but the public ctor. The same class having its instance () method called will result in ... Another instance. Just another example of the mess you can get into when, as you said, you don't know what you (or the engine) is doing or, in this case the guy who hadn't broken past the C++11 barrier.

________________________________
From: Ulf Hermann <ulf.hermann at qt.io>
Sent: Thursday, October 26, 2023 7:53:17 PM
To: Mike Trahearn <mtrahearn at topcon.com>; interest at qt-project.org <interest at qt-project.org>
Subject: Re: [Interest] sharing singleton instance between C++ and QML

> For the record it is actually possible (I proved it) to create multiple
> instances of the same singleton with only one engine using a singleton
> published from C++ if you concoct your C++ side, um,  poorly. But that's
> another matter for people stuck before C++11...

I've fixed QTBUG-116432 if that's what you're referring to. See
https://urldefense.com/v3/__https://codereview.qt-project.org/c/qt/qtdeclarative/*/499804__;Kw!!Nbma_1s!rH6byrSG3I_5v7Wd9tY07sjElp_I6yu3h69YM3qJJf0UY9Z0QhcQuqxwOrzSlW-dU-3Zuw8toj3av3L7RlO9$

> But for the lay person, what is wrong with ensuring the single singleton
> approach and why is it so important to you that QML engines MUST own
> their own singletons?

There are two major reasons:

1. Object ownership: Objects returned from methods (also the create()
method) are supposed to be owned by the engine. People don't realize and
don't setObjectOwnership() and then their program crashes when the
engine terminates and tries to delete the singleton.

2. Thread affinity: The singleton the engine creates lives in the
engine's thread. If the singleton returned from create() lives in a
different thread and you're not very careful, you get a horrible mess.
This can easily happen if your singleton comes from "somewhere" you
don't control.

Indeed the same problems surface if you return an object from an
invokable method, but singletons are a much more prominent feature in
the language, especially since they can often replace context
properties. Therefore, I'm spending more effort on recommending the
safest possible method to create singletons.

> The create() method does require setting C++ ownership (but as we
> discussed, this breaks down with QML_FORIEGN registrations.

I guess this is about https://urldefense.com/v3/__https://bugreports.qt.io/browse/QTBUG-111169__;!!Nbma_1s!rH6byrSG3I_5v7Wd9tY07sjElp_I6yu3h69YM3qJJf0UY9Z0QhcQuqxwOrzSlW-dU-3Zuw8toj3av3b15YFV$  ? If
so, the problem is not with any and all QML_FOREIGN registrations. It's
just that the auto-generated registrations assume the engine owns the
object.

best regards,
Ulf
Confidentiality Notice: This message (including attachments) is a private communication solely for use of the intended recipient(s). If you are not the intended recipient(s) or believe you received this message in error, notify the sender immediately and then delete this message. Any other use, retention, dissemination or copying is prohibited and may be a violation of law, including the Electronic Communication Privacy Act of 1986.   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20231026/5c26ca98/attachment.htm>