Как уже упоминалось другими авторами, ключевая проблема заключается в том, чтобы вы никогда не прикасались к другому не-кроссплатформенному API без Qt. Или даже другой кроссплатформенный API, не относящийся к Qt, если вы используете Qt, то вам, видимо, нужно это сделать, это всеобъемлющая структура, и по большей части придерживаться Qt проще, чем переходить к чему-либо другому. Есть некоторые приятные преимущества, так как основные примитивы в вашей программе будут работать одинаково повсюду. (То есть QString в вашем сетевом коде будет таким же, как QString в вашем коде интерфейса.) В отношении переносимости, если вы остаетесь внутри API, предоставляемого Qt, он должен работать на нескольких платформах.
В некоторых областях вам может понадобиться вызвать некоторые функции Qt, которые предоставляют определенные кроссплатформенные настройки, более важные для некоторых платформ, чем другие (например, значки док-станции), и у вас сразу не будет готового приложения на всех трех платформах. Но в целом вы должны оставаться очень близко к приложению, которое компилируется и работает на всех трех. (Попробуйте использовать qmake или аналогичную систему сборки, поскольку процесс сборки приложений Qt зависит от платформы. Различные флаги и т. Д.)
Есть некоторые странные проблемы, которые возникают, когда вы смешиваете Qt с другими API, такими как OpenGL, в частности, то, как Windows блокирует контексты GL, отличается от того, как это делают OS X и Linux, поэтому, если вы намереваетесь использовать OpenGL с несколькими потоками, попробуйте периодически компилировать на других платформах, чтобы убедиться, что ничего не сломано. Это также быстро укажет на области, где вы могли непреднамеренно использовать API не кроссплатформенной системы.
Я использовал Qt вместе с командой для создания многопоточной трехмерной многопользовательской сетевой игры в реальном времени (читай: нетривиальное приложение, полностью использующее многие области Qt), и мы были просто поражены эффективность способности Qt поддерживать несколько платформ. (Мы разрабатывали для OS X, ориентируясь на Windows, и я регулярно следил за тем, чтобы он по-прежнему работал и на Linux.) Мы обнаружили только несколько специфичных для платформы ошибок, почти все из которых возникли из-за использования не-Qt API, таких как OpenGL. (Что действительно должно вам кое-что сказать, что OpenGL больше боролся за использование кроссплатформенности, чем Qt.)
В конце опыта мы были довольны тем, как мало времени нам нужно было потратить на устранение ошибок, связанных с платформой. Было удивительно, насколько хорошо мы могли сделать приложение с графическим интерфейсом для окон, учитывая, что практически никто из команды не использовал его в качестве основной платформы разработки в рамках проекта.
Но проверяйте рано и часто. Я не думаю, что ваш подход - написать целое приложение, а затем протестировать - хорошая идея. Это возможно с Qt, но маловероятно, если у вас нет опыта написания переносимого кода и / или вы новичок в Qt.