I'd probably go for an interface class, living inside the std::thread, inheriting from QObject and running its own QEventLoop.

From what I understand only the calling thread does not have anything Qt-based. In order to emit a signals there is no need to start an event loop inside that non-Qt thread. Only a receiving slot would require an event loop. Or am I wrong about this?

The quickest way would certainly be using invokeMethod. However, if you can (and are willing to) using signals is always better. If you don't want to introduce any Qt into that thread (yet) you can have a regular C++ function inside some existing Qt code and call that. This function can either use invokeMethod or even emit a signal for your.

If it is inevitable to keep Qt out of your thread (in the long run) it makes sense to create something derived from QObject to be used inside your non-Qt thread. Then you can emit a signal using this object. I don't think you need anything special in the calling thread. emit is just a Qt keyword that gets removed by the preprocessor. From the compiler's point of view emitting a signal is just calling a regular member function. (The member function for the signal is generated by moc.) You need to be careful about object lifetimes. The calling object needs to live long enough for the slot to be executed. If the calling or receiving object in a connect statement is deleted, all queued slot invocations are also removed. Also, as your non-Qt thread does not have an event loop you cannot use deleteLater() to delete the object. If you cannot guarantee that your non-Qt thread runs long enough for the slot to be executed (or rather at least started) inside the Qt thread (and thus cannot guarantee a long lifetime for the QObject-derived object) using invokeMethod is the safest way. Maybe it even makes the most sense to use invokeMethod if you don't rely on member variables of the calling object, but instead hand over all data necessary for the slot as function arguments. It certainly avoid thinking about object lifetimes (and thread lifetimes).

But if you develop an application with Qt, why not use QThread anyway?

I agree. But don't you think Mr @Perdrix is going to say "because it's already in someone else's code which I don't want to change but instead work with"? :)

We've seen an implementation in this topic, that circumvents missing QObject inheritance / event loop. It implements methods in a QObject wrapping a QMetaObject::invokeMethod() call on itself. The caller just calls the wrapper from another thread. While it might technically work, I would clearly not recommend it. Instead, make the caller inherit from QObject and let it live in another QThread. All problems solved cleanly.

a non-Qt thread can use QMetaObject::invokeMethod() to call a slot if it has access to a receiving object but not a sending one to do a connect(). Right?

Yes. But imo it's better to define a signal in the receiver which then does the thread context switch.

Yes, but the question was if it can be invoked from a std::thread (or other non QThread based one). Nothing about what object it is 🙂

Oh indeed! And the reference links are about that, e.g. the second one is about

I want to emit a signal from a C++ thread (std::thread) in Qt.

I just meant that OP is going to need to Qt objects around from somewhere in the thread. I agree with you that emit signal is the obvious route. But, just for the record, a non-Qt thread can use QMetaObject::invokeMethod() to call a slot if it has access to a receiving object but not a sending one to do a connect(). Right?

Am I right, Christian?

Yes, but the question was if it can be invoked from a std::thread (or other non QThread based one). Nothing about what object it is 🙂

You will also a need a receiving QObject, for both cases. The Qt event loop needs to be running in the receiver thread to dispatch the slots.

Am I right, Christian?

References:
https://stackoverflow.com/questions/41044526/qt-5-emit-signal-from-non-qt-thread
https://stackoverflow.com/questions/24982324/qt-emit-a-signal-from-a-c-thread
https://www.qtcentre.org/threads/65029-Emitting-signal-from-a-non-Qt-Thread