Hi Ulf, You have mentioned this foot gun (the create method ) to me before also. But you have only ever broadcast your dislike for the gun. Please could you explain why it is not a good idea to have single singletons. So far your "duplicate it in a wrapper" is not very nice way for maintenance by your own admission. Unless you could have two class types that somehow inherit the property declarations of a base and then it might be easier. But still not nice. How do you like connect signals?! Yep. Another foot gun right there.
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... 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? It is not the only time or place that QML gets a stick poked in its GC from C++: The create() method does require setting C++ ownership (but as we discussed, this breaks down with QML_FORIEGN registrations. Using the create method means you can make ctors private which prevents bozos from trying to manually "new" them from C++. Such folk exist unfortunately. But C++ objects returned from slots or invokables are also subject to the same unintentional weaponry, by necessity else your app may well crash. In this case the instrument of choice is more like a lasso than a gun to keep the GC in check. Your seasoned wisdom as always is appreciated. Mike ________________________________ From: Interest <interest-boun...@qt-project.org> on behalf of Ulf Hermann via Interest <interest@qt-project.org> Sent: Thursday, October 26, 2023 4:50:54 PM To: interest@qt-project.org <interest@qt-project.org> Subject: Re: [Interest] sharing singleton instance between C++ and QML The very common misconception I keep reading over and over is that C++ singletons should be the same as QML singletons. They generally aren't. You can shoehorn a C++ singleton into a QML one, but if you can avoid that exercise, you should avoid it. The usual way to declare a QML singleton is just the same as any old QML object type: You write a QObject-derived class with a number of properties and invokable methods. You make sure it has a default constructor the QML engine can use, and you add QML_ELEMENT. Then you add QML_SINGLETON in addition. That's it. Each QML engine will create at most one instance of this type. Yes, there can be more than one instance in total if there is more than one engine. Yes, the QML engine absolutely wants to own your singleton. And that saves _you_ headaches because now you don't have to care about your singleton's life cycle vis-a-vis the various engines that may be messing with it. If you have some actually singular data you want to serve from your singleton you still can. Your singleton object can keep a pointer to the singular data and return it from its property getters or manipulate it from its invokable methods. Now, as always, you _can_ shoot your foot if you really want to. Here is how you find the gun: If your singleton does not have a default constructor the engine can use, but the engine instead finds a static method "Foo *create(QJSEngine *, QQmlEngine *)", it will use that to obtain the singleton. The method can also be defined on the QML_FOREIGN wrapper in case you cannot touch the actual class at all. In that method you can go to town with your singleton. You can create it on the fly or retrieve it from somewhere. You can declare its object ownership. You can decide yourself which object to return for which engine. You should probably check if the thread affinity matches, but if you don't, it's your problem. _______________________________________________ Interest mailing list Interest@qt-project.org https://urldefense.com/v3/__https://lists.qt-project.org/listinfo/interest__;!!Nbma_1s!u1NPXydiCYxPMheDPd70aoCSd30xAaPsdz6wREZgMCqRso2uZPGRF84WAzEaPM9I_Jmmamw2mzlGZvKC22Zo4w$ 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
