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.herm...@qt.io> Sent: Thursday, October 26, 2023 7:53:17 PM To: Mike Trahearn <mtrahe...@topcon.com>; interest@qt-project.org <interest@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.
_______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
