Работа над кроссплатформенной библиотекой

Question

Каковы лучшие практики написания кроссплатформенной библиотеки на C ++?

Моя среда разработки - Eclipse CDT в Linux, но моя библиотека также должна иметь возможность компилироваться в Windows (например, из Visual C ++).

Спасибо.

Answer 1

В некоторой степени это будет зависеть от того, что именно ваша библиотека должна выполнить.

Например, если вы разрабатываете приложение с графическим интерфейсом, вам следует сосредоточиться на использовании хорошо протестированной кроссплатформенной инфраструктуры, такой как wxWidgets .

Если ваша библиотека зависит главным образом от файлового ввода-вывода, вам следует убедиться, что вы используете существующую хорошо протестированную кроссплатформенную библиотеку абстракций файловой системы, такую ​​как Boost Filesystem .

Если в вашей библиотеке нет ничего из вышеперечисленного (т. Е. Не существует хорошо протестированных кроссплатформенных фреймворков, которые вы можете использовать), лучше всего убедиться, что вы придерживаетесь стандарта C ++ в той же мере насколько это возможно (это означает, например, не #include <linux.h> или <windows.h>). Когда это невозможно (т. Е. Ваша библиотека читает необработанные звуковые данные с микрофона), вы должны убедиться, что подробности реализации для данной платформы достаточно абстрагированы, чтобы свести к минимуму работу в портировании вашей библиотеки на другую платформу.

Answer 2

Насколько мне известно, есть несколько вещей, которые вы можете сделать:

1. Вы можете разделить код платформы для разных пространств имен.

2. Вы можете использовать идиому PIMPL , чтобы скрыть код конкретной платформы.

3. Вы можете использовать макросы, которые знают, какой код компилировать (в этом случае код будет зависеть от платформы). Проверьте эту ссылку для получения дополнительной информации.

4. Проверьте вашу библиотеку в разных средах.

5. В зависимости от того, что вы делаете, может быть полезно использовать такие библиотеки, как Boost, потому что это не относится к конкретной платформе. Недостатком (или, возможно, хорошей стороной) является то, что вы будете вынуждены использовать библиотеки, которые вы включили.

Answer 3

Пара предложений из моего практического опыта:

1) Убедитесь в регулярной компиляции исходных кодов на ваших целевых платформах. Не ждите до конца. Это помогло бы указать на ошибки на ранней стадии. Используйте систему непрерывной сборки - это значительно облегчает жизнь.

2) Никогда не используйте заголовки для конкретной платформы. Даже для написания собственного кода - для всего, что вы знаете, некоторые вещи в заголовке Windows могут ожидать строку, которая была ABC в XP, но была заменена на ABC.12 в Win7.

3) Используйте идеи из STL и BOOST, а затем опирайтесь на них. Никогда не считайте, что это панацея от проблем - STL легко доставить с вашим кодом, а BOOST - нет.

4) Не используйте специфичные для компилятора конструкции, такие как __STDCALL. Это требует ада.

5) Один и тот же код при компиляции с аналогичными параметрами компилятора в g ++ и cl может привести к другому поведению. Пожалуйста, имейте под рукой копию вашего руководства по компилятору.

Answer 4

Это на самом деле так же просто, как «не использовать ничего специфичного для платформы». Изобилие свободно доступных инструментов, доступных в наши дни, делает написание кросс-платформенного кода на C ++ совсем несложно. В тех редких, но редких случаях, когда вам действительно нужно использовать API для конкретных платформ, просто выделите их через #defines или, на мой взгляд, лучше .cpp файлы для каждой платформы.

Есть много альтернатив для кроссплатформенных библиотек, но мои личные предпочтения:

• GUI: Qt
• Абстракция ОС (хотя сама Qt отлично справляется со всем этим): Boost
• Межплатформенные Makefile: CMake

Последний, CMake, был огромной помощью для меня за последние несколько лет в сохранении моей среды сборки в здравом уме при выполнении двойной разработки для Windows и Linux. У него довольно крутая кривая обучения, но как только он запущен и работает, он работает исключительно хорошо.

Answer 5

вопрос, как указано, является немного абстрактным. Но вы можете дать QT внимание

Answer 6

Каждый раз, когда я работаю над чем-то вроде этого, я пытаюсь создать его в различных средах, которые я хочу поддерживать. Точно так же, если вы создавали веб-страницу и хотели убедиться, что она работает в IE, Firefox и Chrome, вы протестируете ее во всех трех браузерах. Протестируйте его в различных средах, которые вы хотите поддерживать, и вы будете знать, для каких систем можно с уверенностью сказать, что он работает.

Answer 7

Вы имеете ввиду помимо непрерывной интеграции и тестирования на целевых платформах? Или кроме использования дизайна для абстрагирования от деталей реализации?

Нет, ни о чем не могу думать.