samokiller, если уж абстрагироваться от чисто системного уровня (который самый быстрый, но сложный в реализации), и уходить в средства многопоточности в Qt, то все будет проще и незначительно медленнее.
1. Захватываем мьютекс, читаем, отправляем сигнал с указателем на данные, который принимают объекты в других потоках. Это потокобезопасно.
2. Потоки читают данные, и присылают сигналы о том, что данные больше не нужны.
3. Отпускаем мьютекс, его захватывает первый процесс, он пишет, отпускает, и goto 1.
Если надо, данные не удаляем, а куда-нибудь сохраняем, с произвольной логикой для потока с БД. Кстати, писать большими кусками транзакционно может быть сильно быстрее, чем мучить БД каждый такт. .
2. На самом деле я уже тысячу лет не писал ничего многопоточного, и вот так сходу не соображу, как тут быть с тремя потоками на два процесса. Семафора возможно хватит и одного, но лучше бы читать в отдельном, третьем потоке, и внутрипроцессную синхронизацию разруливать отдельно.
3. Если у вас после завершения первого процесса есть возможность некоторое время ещё писать данные в БД, то можно что-то думать, иначе отставание будет всё время накапливаться, и по итогу ни в один буфер не поместится.
б) Смотря что считать сложным интерфейсом, например вот это я реализовал с помощью визуального редактора и таблиц стилей, в коде была только пара виджетов, типа календаря и таблицы с drag-n-drop. Там есть возможность вкладывать одну форму в другую, так что если говорить о стандартных элементах, то сложность интерфейса и размер проекта не ограничены.
Даже если предположить, что в каждом лейбле происходит такая избыточная инициализация, то всё, чем это грозит — увеличение времени запуска приложения на несколько миллисекунд, никто и не заметит разницы.
Я не вижу смысла отказываться от использования дизайнера, тратить кучу времени и сил ради призрачной оптимизации времени запуска.
а) Новичкам такое сделать сложно, они 146% всё скидают в кучу.
б) Я не понимаю, в чем проблема, когда в moc_*.cpp автоматически, читай бесплатно генерируется "лишний код", который в вам в ином случае придётся писать руками, и тогда "лишнее" уже будет непосредственно в файлах проекта.
Признайтесь, вам просто было лень потратить несколько часов, и визуальный редактор интерфейсов вы так и не освоили, потому пишете всё руками.
Игорь Джулай, Александр, это очень плохой совет, редактор ui использовать можно и нужно, а верстать руками интерфейсы в плюсах — моветон.
Это усложняет поддержку, код интерфейса смешивается с логикой. Вот в QML — там да, надо верстать руками, под это специальный декларативный язык написали, и с логикой на С++ он не смешивается.
CaptainJustness, кросс-компиляция с ARM64 + MacOS на x86_64 + Windows технически возможна, но красноглазить придется порядком. На сегодняшний день запустить Windows в виртуалке на Маке с М1 невозможно.
