Ich sehe deinen Standpunkt. Nur noch ein paar Punkte:
Ich entwerfe Software anderst. Wenn ich ein MT-Konzept verfolge (z.B. bei einer Maschinensteuerung), dann läuft der Thread bereits von Anfang an. Ich übergebe dann Jobs und kriege die Antworten zurück. Für einfache Aufgaben, welche nur kurzfristig parallelisiert werden müssen (z.B. das Konvertieren von 20 Bilder) würde ich QtConcurrent nehmen.du bereitest die daten fuer den Thread auf, du startest den thread. Wenn der Thread fertig ist, gibts ne Nachricht, und der thread beendet sich dann gleich. Die resultate liegen dann an ner vordefinierten stelle.
Thema "Performance" und Eventloop: du argumentierst da stehts mit etwas, was du nicht genau beziffern kannst: hast du das mal ausgemessen (CPU-Zeit/RAM-Verbrauch mit/ohne Eventloop)? Meine Einschätzung: das ist vernachlässigbar.. sogar auf kleinen Rechnern wie z.B. meinem Telefon..
Thema "Performance" und Call-By-Value: Korrekt: da werden Kopien zwischengelagert. Was solls: entweder das sind nur wenige sporadische Daten und man nimmt die paar Bytes in Anspruch, oder man versendet QObject-Pointer (deleteLater() ist thread-safe und garantiert, dass das QObject in der richtigen Eventloop (=im Erzeuger-Thread) gelöscht wird).
Ok.. wir sind da ziemlich in's Detail gegangen.. ich belasse es dabei.
Denk einfach daran: nicht alle haben Echtzeitanwendungen. Es schadet meist nichts, von der heutigen Hardware ein paar Bytes und CPU-Zyklen der Flexibilität zu spenden
Happy Hacking!
