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

[Mike Trahearn]

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-bounces at qt-project.org> on behalf of Ulf Hermann via Interest <interest at qt-project.org>
Sent: Thursday, October 26, 2023 4:50:54 PM
To: interest at qt-project.org <interest at 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 at 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.   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20231026/bc46664b/attachment.htm>