Искусство программирования для Unix

Реймонд Эрик Стивен

19.2.3.6. Рекомендованные практические приемы переносимости кода С/С++

При написании программ на С используйте полные ANSI-функции. В частности, используйте прототипы функций, которые помогают выявить несовместимость между модулями. Старые компиляторы в стиле K&R — древняя история.

Не полагайтесь на специфические для некоторых компиляторов функции, такие как GCC-параметр -pipe или вложенные функции. Они впоследствии повлияют на чужие порты в не-Linux и He– GCC-системе.

Необходимый

для обеспечения переносимости код должен быть изолирован в отдельной области и отдельном наборе исходных файлов (например, в подкаталоге os). Компилятор, библиотека и интерфейсы операционной системы с проблемами переносимости должны быть абстрагированы в файлы данного каталога.

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

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

Рекомендуется всегда писать уровень переносимости на основе функции, а не на основе платформы. Попытки создания отдельных уровней переносимости для каждой поддерживаемой платформы приводят к многочисленным проблемам обновления и обслуживания. "Платформа" всегда выбирается на основе по крайней мере двух параметров: компилятор и версия библиотеки/операционной системы. В некоторых случаях используются три фактора, как когда Linux-поставщики выбирают библиотеку С независимо от версии операционной системы. В случае с М-поставщи-ками, /V-компиляторами и О-версиями операционных систем, количество платформ быстро превышает пределы досягаемости любых коллективов разработчиков, кроме крупнейших. С другой стороны, при использовании стандартов языков и систем, таких как ANSI и POSIX 1003.1, набор функций является относительно ограниченным.

Выбор уровня переносимости можно осуществлять либо по строкам кода, либо по компилированным файлам. Нет различий при выборе альтернативных строк кода на платформе или одного из нескольких различных файлов. Практическое правило заключается в том, чтобы перенести код переносимости для различных платформ в отдельные файлы, когда реализация значительно отличается (распределение общей памяти в Unix и Windows), и оставлять код переносимости в одном файле, когда различия минимальны (например, в зависимости от использования функции gettimeofday, clock_gettime, f time или time для определения текущего времени суток).

За пределами уровня переносимости необходимо придерживаться следующей рекомендации.

Директивы #ifdef и #if являются последним средством, обычно признаком неудачного воображения, чрезмерной дифференциации

продукта, неоправданной "оптимизации" или накопленного мусора. Их использование в середине кода — бедствие. Образцовый пример — /usr/include/stdio. h из GNU.

Дуг Макилрой.

Использование директив #if def и #if допустимо (если хорошо контролируется) внутри уровня переносимости. За его пределами необходимо упорно пытаться заключить их в обусловленные #includes, исходя из символов функций.

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

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

19.2.4. Хорошая практика создания дистрибутивов

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

19.2.4.1. Убедитесь, что архивы всегда распаковываются в один новый каталог

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

Вместо этого следует убедиться, что все архивные файлы имеют общий каталог, который назван именем проекта, для того чтобы они распаковывались в один каталог верхнего уровня непосредственно в текущем каталоге. Традиционно имя каталога должно быть таким же, как именная часть архива. Например, предполагается, что архив с именем f оо- 0 .23. tar. gz распаковывается в подкаталог f оо- 0.23.

В примере 19.1 демонстрируется решение для make-файла, которое позволяет реализовать указанный принцип в предположении, что каталог дистрибутива называется "foobar", a SRC содержит список файлов дистрибутива.

Пример 19.1. make– правила для tar-архива

foobar-$(VERS).tar.gz:

®ls $(SRC) I sed s:^A:foobar-$(VERS)/: >MANIFEST ®(cd ..; In -s foobar foobar-$(VERS))

(cd ..; tar -czvf foobar/foobar-$(VERS).tar.gz "cat foobar /MANIFEST" )

®(cd ..; rm foobar-$(VERS))

19.2.4.2. Включайте в дистрибутив README-файл

В дистрибутив программы следует включать файл README, который является путеводителем по дистрибутиву. Согласно давнему соглашению (созданному самим Деннисом Ритчи до 1980 года, и распространенному в Usenet в начале 1980-х годов), данный файл является первым файлом, который будут читать бесстрашные исследователи, после того как распакуют исходный код.