Ответ 1

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.
• Эпоха началась в 1721 году.
• time_t double

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

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

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

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

5. Поймите, что стандарт С++ обеспечивает довольно ограниченную среду программирования

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

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

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

6. Утвердите, что вы принимаете

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

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

Ответ 2

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

Ответ 3

Ваш вопрос:

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

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

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

Привет

БВУ

Ответ 4

Избегайте библиотек, специфичных для платформы.

Ответ 5

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

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

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

  • API платформы/ОС
  • Цепочки инструментов
  • Особенности языка

• Тест, развертывание. Промыть и повторить.

Ответ 6

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

Ответ 7

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

Ответ 8

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

Ответ 9

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

Ответ 10

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

Тем не менее, чтобы быть портативным, вам необходимо:

• Избегайте Win32
• Избегайте POSIX (что раздражает... Вы можете просто использовать Cygwin для поддержки Windows)
• Избегайте какой-либо конкретной платформы. Обычно это ограничивает вас графикой wxWindows, GTK и QT.
• TEST. Убедитесь, что он работает.
• Не принимайте ничего. Windows странно и использует \r\n, поэтому будьте осторожны.
• Я думаю, что Visual С++ на окнах дает вам предупреждения о "небезопасных функциях c" и просит вас использовать "безопасные", которые не являются стандартными. Не поддавайтесь попытке Microsoft монополизировать вашу программу.

Некоторые вещи помогут:

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

Ответ 11

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

Ответ 12

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

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

Подход inbetween состоит в том, чтобы иметь чистое портативное ядро ​​с несколькими встроенными GUI.

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