Чтение онлайн

Переносимость является чем-то вроде Святого Грааля; всегда недостающим впоследствии, но не всегда достижимым и определенно нелегким. Есть несколько аспектов написания переносимого кода. GNU Coding Standards обсуждает многие из них. Но есть и другие стороны. При разработке принимайте переносимость во внимание как на высоком, так и на низком уровнях. Мы рекомендуем следующие правила:

Соответствуйте стандартам

Хотя это может потребовать напряжения, знакомство с формальными стандартами языка, который вы используете, окупается. В частности, обратите внимание на стандарты ISO 1990 и 1999 гг. для С и стандарт 2003 г. для С++, поскольку большинство программ Linux создано на одном из этих двух языков.

В промышленности также широко поддерживается стандарт POSIX для интерфейса библиотечных и системных вызовов, хотя он и большой. Написание в соответствии с POSIX значительно повышает шансы успешного переноса вашего кода и на другие системы, помимо GNU/Linux. Этот стандарт вполне читабелен; он концентрирует в себе десятилетия опыта и хорошей практики.

Выбирайте для работы лучший интерфейс

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

, которую довольно легко запрограммировать самому или вставить из библиотеки GLIBC).

Изолируйте проблемы переносимости за новыми интерфейсами

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

Используйте для конфигурирования Autoconf

По возможности избегайте

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

1. The С Programming Language, 2nd edition, by Brian W. Kernighan and Dennis M. Ritchie Prentice-Hall, Englewood Cliffs, New Jersey, USA, 1989. ISBN: 0-13-110370-9 [25] .

Это «библия» С, охватывающая версию стандарта С 1990 г. Это довольно сжатая книга, с большим количеством информации, помещенной в поразительно небольшое число страниц. Вам может потребоваться прочитать ее более одного раза; это стоит затраченных усилий.

2. С, A Reference Manual. 5th edition, by Samuel P. Harbison III and Guy L. Steele, Ji. Prentice-Hall, Upper Saddle River, New Jersey, USA, 2002. ISBN: 0-13-089592-X.

Это тоже классическая книга. Она охватывает оригинальный С, а также стандарты 1990 и 1999 гг. Поскольку она современна, она служит ценным дополнением к первой книге. Она охватывает многие важные темы, такие, как интернациональные типы и библиотечные функции, которых нет в книге Кернигана и Ричи.

3. Notes on Programming in С, by Rob Pike, February 21,1989 Доступна через множество веб-сайтов. Возможно, чаще всего упоминаемым местом является

. (Многие другие полезные статьи доступны там же на один уровень выше: .) Роб Пайк много лет работал в исследовательском центре Bell Labs, где были созданы С и Unix, и проводил там изыскания. Его замечания концентрируют многолетний опыт в «философию ясности в программировании», это стоит прочтения.

4. Различные ссылки на

. Этот сайт включает заметки Роба Пайка и несколько статей Генри Спенсера (Henry Spencer). Особенно высокое положение занимает «Рекомендуемый стиль С и стандарты программирования» (Recommended С Style and Coding Standards), первоначально написанный на сайте Bell Labs Indian Hill.

• «Файлы и процессы» суммируют мировоззрение Linux/Unix. Трактовка файлов как потоков байтов, а устройств как файлов, и использование стандартных ввода, вывода и ошибки упрощают построение программ и унифицируют модель доступа к данным. Модель прав доступа проста, но гибка, и приложима как к файлам, так и каталогам.

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

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

• GNU Coding Standards описывает написание программ GNU. Она предусматривает многочисленные ценные методики и руководящие принципы для создания надежного, практичного программного обеспечения. Принцип «никаких произвольных ограничений» является, возможно, единственным наиболее важным из них. Этот документ является обязательным для прочтения серьезными программистами.

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

1. Прочтите и прокомментируйте статью Ричарда М. Столмена «Проект GNU» (Richard M. Stallman, «The GNU Project») [26] , первоначально написанную в августе 1998 г.

Первой задачей любой программы обычно является интерпретация опций и аргументов командной строки. Данная глава рассматривает, как программы С (и С++) получают аргументы своей командной строки, описывает стандартные процедуры для разбора опций и бросает взгляд на переменные окружения.