О чем следует помнить в первую очередь при написании кроссплатформенных приложений на C? Целевые платформы: 32-разрядный ПК на базе Intel, Mac и Linux. Я особенно ценю ту универсальность, которую Jungle Disk имеет в своей настольной версии USB ( http://www.jungledisk.com/desktop/download.aspx )
Каковы советы и «подводные камни» для этого типа разработки?
В течение нескольких лет я поддерживал сетевую библиотеку ANSI C, которая была перенесена примерно на 30 различных ОС и компиляторов. В библиотеке не было компонентов с графическим интерфейсом, что делало ее проще. В итоге мы абстрагировали в выделенные исходные файлы любую процедуру, которая не была согласована на разных платформах, и использовали #define там, где это уместно, в этих исходных файлах. Это изолировало код, настроенный для каждой платформы, от основной бизнес-логики библиотеки. Мы также широко использовали typedef и наши собственные выделенные типы, чтобы при необходимости можно было легко изменить их для каждой платформы. Это упростило перенос на 64-битные платформы.
Если вы хотите иметь компоненты с графическим интерфейсом, я бы посоветовал взглянуть на наборы инструментов для графического интерфейса, такие как WxWindows или Qt (оба являются библиотеками C++).
Старайтесь избегать зависящих от платформы #ifdef, так как они имеют тенденцию расти экспоненциально, когда вы добавляете новые платформы. Вместо этого попробуйте организовать свои исходные файлы в виде дерева с независимым от платформы кодом в корне и зависящим от платформы кодом на «листьях». На эту тему есть хорошая книга Multi-Platform Code Management. Образец кода в ней может показаться устаревшим, но идеи, описанные в книге, по-прежнему блестяще актуальны.
В дополнение к ответу Кайла я настоятельно рекомендую против пытаться использовать подсистему Posix в Windows. Он реализован на абсолютно минимальном уровне, так что Microsoft может заявить о «поддержке Posix» в поле для галочки на листе функций. Возможно, кто-то там действительно использует его, но я никогда не сталкивался с этим в реальной жизни.
Конечно, можно писать кроссплатформенный код на C, просто нужно знать о различиях между платформами и тестировать, тестировать, тестировать. Модульные тесты и решение CI (непрерывная интеграция) будут иметь большое значение для обеспечения того, чтобы ваша программа работала на всех ваших целевых платформах.
Хороший подход состоит в том, чтобы изолировать зависящие от системы вещи в одном или максимум нескольких модулях. Обеспечьте системно-независимый интерфейс от этого модуля. Затем создайте все остальное поверх этого модуля, чтобы оно не зависело от системы, для которой вы компилируете.
XVT имеет кросс-платформенный GUI C API, который разработан более 15 лет и находится поверх собственных наборов инструментов для работы с окнами. См. WWW.XVT.COM.
Они поддерживают как минимум LINUX, Windows и MAC.
Старайтесь писать как можно больше с помощью POSIX. Mac и Linux изначально поддерживают POSIX, а в Windows есть система, которая может его запускать (насколько мне известно, я никогда ее не использовал). Если ваше приложение является графическим, и Mac, и Linux поддерживают библиотеки X11 (Linux изначально, Mac через X11.app), и существует множество способов заставить приложения X11 работать в Windows.
Однако, если вы ищете действительно многоплатформенное развертывание, вам, вероятно, следует переключиться на такой язык, как Java или Python, который способен запускать одну и ту же программу на нескольких системах с небольшими изменениями или без изменений.
Редактировать: я только что скачал приложение и посмотрел файлы. Похоже, у него есть двоичные файлы для всех трех платформ в одном каталоге. Если вы беспокоитесь о том, как писать приложения, которые можно перемещать с компьютера на компьютер без потери настроек, вам, вероятно, следует записать всю свою конфигурацию в файл в том же каталоге, что и исполняемый файл, и не трогать реестр Windows или создавать какие-либо каталоги с точками в домашняя папка пользователя, запустившего программу на Linux или Mac. А что касается создания кросс-дистрибутивного двоичного файла Linux, 32-битный POSIX/X11, вероятно, будет самым безопасным выбором. Я не уверен, что использует JungleDisk, так как сейчас я на Mac.
Существует довольно мало переносимых библиотек, просто примеры, с которыми я работал в прошлом.
1) glib и gtk+
2) либкурл
3) либапр
Они охватывают почти все платформы и поэтому являются чрезвычайно полезным инструментом.
Posix хорош для Unices, но я сомневаюсь, что он так хорош для Windows, кроме того, у нас нет ничего для переносимых графических интерфейсов.
Я также поддерживаю рекомендацию разделять код для разных платформ на разные модули/деревья вместо ifdef.
Также рекомендую заранее проверить, в чем отличия ваших платформ и как их можно абстрагировать. Например. это некоторые вещи, связанные с ОС (например, раздражающие CR, CRLF, LF в текстовых файлах) или аппаратные средства. Например. ранее упомянутая совместимость с posix не мешает вам
int c;
fread(&c, sizeof(int), 1, file);
Но на разных аппаратных платформах расположение внутренней памяти может быть совершенно разным (порядок байтов), что вынуждает вас использовать функции преобразования на некоторых целевых платформах.
