Здравствуйте, AlexGin, Вы писали:

AG>Возможно, стоит применять Qt многопоточность даже для Windows реализации.
AG>Тут надо проеэкспнриментировать — посчитать производительность, как она будет в сравнении с WinAPI.

Думаю пункт 1, то есть WinAPI существенной роли не сыграет, в особенности, если понимать на что влияют технологии многопоточного программирования Qt.

http://doc.qt.io/qt-5/threads-technologies.html
1) QThread: Low-Level API with Optional Event Loops
2) QThreadPool and QRunnable: Reusing Threads
3) Qt Concurrent: Using a High-level API

Третий пункт тоже не имеет значения:

AG>Дополнительная красота третьего пункта — если будет серверное приложение, без GUI, то не нужно "притягивать за уши" дополнительные библиотеки.

Я просто беру и создаю в QtCreator консольное приложение:

#-------------------------------------------------
#
# Project created by QtCreator 2016-07-06T21:15:33
#
#-------------------------------------------------

QT       += core

QT       -= gui

TARGET = untitled
CONFIG   += console
CONFIG   -= app_bundle

TEMPLATE = app


SOURCES += main.cpp

Немного причёсываем:

TARGET = untitled
TEMPLATE = app

QT -= gui

CONFIG += console
CONFIG -= app_bundle

SOURCES += main.cpp

А потом можно создать составной проект с общими файлами и включёнными проектами gui-клиента и сервера. Или вот маленькая переделка кода:

#include <QDebug>

int main(int argc, char *argv[])
{
    qDebug() << "Hello World!";
    return 0;
}

В дебиане нажимаем Ctrl+Alt+F1, вводим root или другого пользователя с паролем и запускаем программу. Потом обратно выход на рабочий стол Ctrl+Alt+F7. Фишка в том, что функционал отвечающий за работу с параллельными потоками исполнения лежит в модуле QtCore. Между прочим, если совместить кроссплатформенные библиотеки, то тоже выйдет неплохое кроссплатформенное решение. Другое дело это не всегда целесообразно, особенно, если можно обойтись средствами Qt.

Ещё когда-то давным давно обсуждали статическую сборку Qt для Windows

Автор:
Дата: 18.12.11

. По прошествии многих лет могу сказать, что идея тоже не целесообразна, хотя всё прекрасно работает. Суть в том, что чем больше программист создаёт себе проблем, тем хуже для него. Отсюда вывод, не создавать надуманных проблем, лучше не идеально работающая система, чем идеальная не работающая.

Я не зря привёл пример компьютеров с низкой и высокой вычислительной мощью. Сдаётся мне в прикладном приложении можно убить месяцы на разработку велосипеда, а школьник Вася Пупкин стандартным функционалом на коленеке сделает так же или даже лучше, плюс ещё и кроссплатформенно. При этом он может и слов таких не знать, которыми обменивались в этой теме.