Переносимость программ

Как убедиться, что моя программа будет полностью портативный?

12 ответов


1. Тест

это необходимое, но не достаточное условие для чего-либо правильно. Чтобы проверить переносимость, вам понадобится несколько платформ и компиляторов.

2. Пишите на стандарт, а не на вашу платформу разработки.

это означает, только делать что-то, если стандарт говорит, что вы можете это сделать. Ожидать только определенного результата, если стандарт говорит, что вы можете ожидать от нее. Используйте только библиотеку или API, если стандарт говорит, что он существует. Стандарт доступен здесь (среди прочих мест):

http://openassist.googlecode.com/files/C%2B%2B%20Standard%20-%20ANSI%20ISO%20IEC%2014882%202003.pdf

это помогает, если вы предполагаете, что:

  • CHAR_BIT равно 9.
  • sizeof (int) равен 5 и int является 37-битным типом. Или 16-битный тип.
  • основной набор символов-EBCDIC.
  • epoc начался в 1721 году.
  • time_t is double

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

3. Используйте самые ограничительные и педантичные параметры компилятора, которые вы можете найти,

это единственный практический способ дать себе разумный шанс достичь (1).

4. Поймите, что "реальные компиляторы" не могут правильно реализовать стандарт или полностью, и сделать некоторые уступки этому факту.

теоретически, нет ничего непереносимого в программе на C++, которая использует export. Если это отличная программа на C++ во всех других отношениях, то она будет работать на любом соответствующем компиляторе c++. Но вряд ли кто-то использует соответствующий компилятор C++, поэтому есть de facto общее подмножество C++, которое вы хотите придерживаться.

5. Поймите, что стандарт C++ обеспечивает довольно ограниченное Программирование среды

некоторые вещи не переносятся в стандартном C++, например, рисование графики на экране, поскольку стандартный C++ не имеет графики или API GUI. Таким образом, нет такой вещи, как "полностью портативная" программа GUI, написанная на C++. Таким образом, вам может потребоваться пересмотреть свою цель, в зависимости от того, что должна делать ваша программа.

если ваша программа требует чего-то, что просто не может быть сделано полностью в стандартном C++, то вы можете сделать вашу программу проще для порта инкапсулирование этого поведения в интерфейсе, который, по вашему мнению, должен быть реализован на всех платформах, о которых вы заботитесь. Затем приступайте к его реализации для каждого из них. Однако это не приводит к "полностью переносимой" программе, поскольку для меня это означает программу, которую вы можете компилировать и запускать без изменений в любой соответствующей реализации c++. Программа, которая может быть портирована на большинство платформ с компилятором c++, вероятно, предполагая, что у них есть экран и мышь, с уникальные разработки, не такая же вещь.

все это может быть слишком далеко, конечно. Вероятно, вы действительно захотите предположить, что CHAR_BIT is 8 (чтение файлов-безумие в противном случае), и, возможно, даже полагаться на GUI-фреймворк, такой как Qt. Но вы сказали "полностью портативный", и одна из главных вещей, которые вам нужно сделать, чтобы написать портативные программы, - это, как правило, выяснить, насколько вы готовы пойти на компромисс по"полностью".

6. Утверждайте то, что вы предполагаете

во время компиляции, если можете, или во время выполнения в противном случае, убедитесь, что если ваша программа требует int, чтобы быть по крайней мере 32 бита (или любой другой), то это будет не шумно, когда это не так. Итак, всестороннее тестовое покрытие будет ловить тех случаях, когда ваша арифметика молча переполняется и дает неправильный ответ, но трудно писать по-настоящему комплексные испытания, и в любом случае тесты могут сделать то же непереносимому ошибок в коде, или кому-то, кто скачал ваш код может не работать с ними все правильно.

при использовании библиотеки, вы эффективно делаете это автоматически. Ты #include некоторый заголовок, и если библиотека недоступна, это немедленно завершится ошибкой. По крайней мере, вы надеетесь, что это будет - возможно, что какая-то другая реализация может иметь заголовок с тем же именем, который делает что-то радикально или тонко другое. Радикальные различия обычно приводят к сбоям компиляции, для тонких различий вы можете проверить на символы препроцессора для идентификации реализаций.


непрерывная интеграция на всех целевых платформах.


Ваш вопрос:

Как убедиться, что моя программа будет полностью портативный?

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

в процессе разработки и тестирования в параллельно на разных платформах и средах, каждый из нас находит свой мешок трюков и исследует свою долю ошибок. Вы сказали в одном комментарии, что работаете в системе Windows. Это нормально. Попробуйте заставить вашу программу работать с компилятором Visual Studio (и средой). Затем установите CygWin с GCC 4.x компилятор люкс. Установите среда IDE и C++ Netbeans и создать проект на основе тех же источников. Netbeans будет использовать Cygwin GCC 4.х. Если ваша скомпилированная программа работает с обеими цепочками инструментов, вы освоили, вероятно, около 90% препятствий переносимости в реальном мире.

в отношении

rbo


избежать платформы библиотеки.


  • сделать его стандартам. По крайней мере, общее подмножество стандарта, реализуемого поставщиками на всех платформах, на которых планируется развертывание приложения.

  • фактор вне части платформы специфические от платформ-независимых одних. Как правило, самый низкий слой или два должны иметь дело с платформой.

  • будьте в курсе изменений:

    • API платформы / ОС
    • цепи!--4-->
    • языковые особенности
  • Тестирование, Развертывание. Промыть и повторить.


Unit test it, на каждой платформе, во время разработки


разработка в наиболее ограничительной среде компиляции. Используйте наименьший набор функций из C++. Разделите зависящие от платформы части кода на отдельные файлы. Разработка среды конфигурации (make) для каждой платформы в составе программного пакета.


избегайте использования библиотек, специфичных для платформы. Если вы можете реализовать желаемую функциональность, используя только STL и BOOST, продолжайте.


убедившись, что использовать только библиотеки, которые фактически существуют на всех целевых платформах, было бы хорошим началом.


невозможно. Что происходит, когда я пишу свою операционную систему со странным компилятором C?

, который сказал, чтобы быть портативным, вам нужно:

  • Избежать С Win32
  • избегайте POSIX (что раздражает... Вы можете просто использовать Cygwin для поддержки Windows)
  • избегайте любой конкретной библиотеки платформы. Это обычно ограничивает вас в графике wxWindows, GTK и QT.

знайте платформы, которые вы собираетесь отправить. Если какое-либо соглашение платформы противоречит стандарту, игнорируйте стандарт. Я серьезно. Например, если вы используете стандарт std::ifstream конструктор, который принимает char* аргумент, вы не сможете открыть файлы с именами файлов Unicode в Windows-you должны использовать нестандартный wchar_t* перегрузки есть. Функциональность потеряна из-за невозможности открыть файлы, которые разрешены и легальны на платформе серьезно перевешивает переносимость, полученную при использовании только того, что знает стандарт; в конце концов, важна функциональность, а не соблюдение определенного стандарта.


Это менее прямой ответ на вопрос, чем ответ в свете других ответов.

вам нужно сбалансировать требование абсолютной переносимости с ожиданиями пользователей платформы - существуют различные основные рекомендации HCI/HIG для Windows, OS X, KDE и Gnome, и ни один из портативных наборов инструментов GUI не будет автоматически давать правильные результаты в каждом (некоторые позволяют применять разные макеты, что является началом).

промежуточный подход иметь чистое портативное ядро с несколькими собственными GUIs.

Это не обязательно (есть много программного обеспечения, которое преуспевает, несмотря на игнорирование конвенций), но это компромисс, который необходимо учитывать, в частности, если есть существующее сильное собственное приложение.