Керниган Б., Пайк Р. Практика программирования
Подождите немного. Документ загружается.
недостатков. Первый его недостаток состоит в том, что требование универсальной
применимости может ограничить либо круг систем, предназначенных для
использования, либо перечень приемлемых языковых конструкций. Второй
недостаток — в некоторых системах производительность программ может оказаться
далекой от совершенства.
Для сравнения двух описанных подходов рассмотрим пару примеров, сделанных по
принципу объединения, и обдумаем, как
они будут выглядеть для пересечения. Как
вы увидите, код, основанный на объединении, уже проектируется как
непереносимый, хотя хорошая переносимость и является вроде бы основной его
целью, а код пересечения получается не только переносимым, но еще и более
простым.
Следующий небольшой фрагмент пытается справиться с системой, в которой по
некоторым причинам
нет стандартного заголовочного файлa stdlib. h:
? #if defined (STDC_HEADERS) || defined (_LIBC)
? #include <stdlib.h>
? #else
? extern void *malloc(unsigned int);
? extern void *realloc(void *, unsigned int);
? #endif
Защитный стиль приемлем, если он применяется время от времени,; а не всегда.
Возникает резонный вопрос: а для скольких еще функций из stdlib. h придется писать
аналогичный код? В частности, если вы собираетесь использовать mall ос и real loc,
то явно потребуется еще и free. А что, если тип unsigned int нетождественен size_t —
правильному типу аргумента для malloc и realloc? Более того, откуда мы знаем, что
STOC_HEADERS и _LIBC определены, и определены корректно? Можем ли мы быть
уверенными в том, что не существует другого имени, которое потребует замены для
другой среды? Любой условный код вроде этого неполон, а значит — непереносим,
поскольку рано или поздно встретится система, не
удовлетворяющая его условию, и
тогда придется редактировать #ifdef. Если нам удастся решить задачу без помощи
условной компиляции, мы избавимся и от проблем, связанных с дальнейшим
поддержанием этого кода.
Итак, проблема, которая решается в рассмотренном примере, существует в
реальности. Так как же нам решить ее раз и навсегда? На самом деле нам просто
надо предположить, что стандартные заголовочные файлы присутствуют во всех
системах всегда; если одного из них нет, то это уже не наши проблемы. Но мы
можем решить и их; для данного случая достаточно вместе с программой поставить
и заголовочный файл, который определяет malloc, realloc и free в точности так, как
этого требует стандарт ANSI С.
Такой файл всегда может быть включен полностью
вместо "заплаток", и мы будем уверены, что нужный интерфейс обеспечен.
Избегайте условной компиляции. Условной компиляцией с помощью ttifdef и
подобных ей директив препроцессора трудно управлять, поскольку информация
оказывается рассеянной по всему коду:
? #ifdef NATIVE
? char *astring = "convert ASCII to native character set";
? #else
? #ifdef MAC
? char *astring = "convert to Mac textfile format";
? #else
? #ifdef DOS
? char *astring = "convert to DOS textfile format";
? #else *„
? char *astring = "convert^ to Unix textfile format";
? #endif /*:?DOS */
? #endif /* ?MAC */
? #endif /* ?NATIVE */
В этом фрагменте, вообще говоря, лучше было бы использовать tfelif после каждого
определения — тогда бы не было такого ненужного скопления tfendif в конце. Однако
главная проблема вовсе не в этом, а в том, что, несмотря на все старания, код плохо
переносим, потому что он ведет себя по-разному в
разных системах, а для работы в
каждой новой системе должен быть дополнен новым Sifdef. Одна-единственная
строка с унифицированным текстом (но на самом деле столь же информативным)
была бы гораздо удобнее, проще и переносимее:
char *astring = "convert
to local text format";
Для этой строки никаких условий не нужно, она будет выглядеть одинаково во всех
системах.
Смешивание управляющей
логики времени компиляции (определяемой
выражениями «if def) и времени исполнения приводит к еще более трудно
воспринимаемому коду:
? #ifndef DISKSYS
? for (i = 1; i <= msg->dbgmsg.msg_total; i++)
? #endif
? #ifdef DISKSYS
? i = dbgmsgno;
? if (i <= msg->dbgmsg.msg_total)
? #endif
? {
?
? if (msg->dbgmsg.msg_"total == i)
?#ifndef DISKSYS
? break; /* больше ожидаемых сообщений нет */
? еще около 30 строк с условной компиляцией
? #endif
? }
Даже будучи явно безопасной, условная компиляция может быть заменена более
простым кодом. Например, tfifdef часто используют для управления отладочным
кодом:
? ftifdef DEBUG
? printf(...);
? tfendif
однако обычное выражение if с константой в условии может делать то же самое:
enum { DEBUG = 0 };
if (DEBUG) {
printf(...);
}
Если DEBUG есть ноль, то большинство компиляторов не сгенерируют для
приведенного фрагмента никакого кода, но при этом они еще и проверят синтаксис.
Секция с #if def, наоборот, может содержать синтаксические ошибки, которые сорвут
компиляцию, как только соответствующее условие #if def окажется
выполнено.
Иногда условия компиляции содержат большие блоки кода:
tfifdef notdef /* неопределенный символ */ ttendif
или
#if О
tfendif
В таком случае этот код лучше вынести в отдельные файлы, которые будут
подключаться при компиляции при соблюдении определенных условий. К этой теме
мы еще вернемся в следующем разделе.
Начиная адаптировать программу к новой среде, не делайте копии
всей программы,
а перерабатывайте исходный код. Скорее всего, вам придется вносить изменения в
основное тело программы, и при редактировании копии вы через какое-то время
получили бы новую, отличающуюся от исходной версию. Изо всех сил стремитесь к
тому, чтобы у вас существовала единственная версия программы; при
необходимости подстроиться под конкретную систему
старайтесь вносить изменения
таким образом, чтобы они работали во всех системах. Измените внутренние
интерфейсы, если надо, но не нарушайте целостности кода; не пытайтесь решить
проблему с помощью #if def. При таком подходе каждое изменение сделает вашу
программу все более переносимой, а не более специализированной. Сужайте
пересечение, а не расширяйте объединение.
Мы уже
привели много доводов против использования условной компиляции, но не
упоминали еще о главной проблеме: ее практически невозможно оттестировать.
Каждое выражение tfif def разделяет всю программу на две по отдельности
компилируемые программы, и определить, все ли возможные варианты программ
были скомпилированы и проверены, очень сложно. Если в один блок tfifdef было
внесено изменение, то может
статься, что изменить надо и другие блоки, но
проверить эти изменения можно будет только в той среде, которая вызовет эти tfifdef
к исполнению. Точно так же, если мы добавляем блок #if def, то трудно изолировать
это изменение, то есть определить, какие еще условия должны быть учтены и в
каких еще местах должен быть
изменен код. Наконец, если некий блок кода должен
быть опущен в соответствии с условием, то компилятор его просто не видит, и
проверить этот блок можно только в соответствующей конфигурации. Вот небольшой
пример подобной проблемы — программа компилируется, если _МАС определено, и
отказывается это делать в противном случае:
flifdef _MAC
printf("This is Macintosh\r");
#else
This will give a syntax error on other systems
#endif
Итак, мы предпочитаем использовать только те возможности, которые присутствуют
во всех средах, где будет исполняться программа. Мы всегда можем
скомпилировать и протестировать весь код. Если что-то вызывает проблемы с
переносимостью, мы переписываем этот кусок, а не добавляем условно
компилируемый код; таким образом, переносимость все время улучшается.
Некоторые большие
системы распространяются с конфигурационными скриптами,
которые помогают приспособить код к локальной среде. Во время компиляции скрипт
проверяет возможности среды: расположение заголовочных файлов и библиотек,
порядок байтов внутри слов, размер типов, уже известные неверные реализации
функций (таких на удивление много) и т. п. — и генерирует параметры настройки или
make-файлы (makefile), которые описывают
нужные настройки для данной ситуации.
Эти скрипты могут быть большими и сложными, они являются важной частью
дистрибутивного пакета и требуют постоянной поддержки. Иногда такие сложные
способы оказываются полезны, но все же, чем переносимее будет ваш код и чем
меньше #if def будет в нем использова-' но, тем проще и безопаснее будет
происходить его
настройка и установка.
Упражнение 8-1
Выясните, как ваш компилятор обрабатывает код, содержащийся внутри условного
блока типа
const int DEBUG = 0;
/* или enum { DEBUG = 0 }; */
/* или final boolean DEBUG = false; */
if (DEBUG) {
}
При каких обстоятельствах компилятор проверяет синтаксис? Когда он генерирует
код?
Если у вас есть доступ к разным компиляторам, поэкспериментируйте с ними и
сравните результаты.
Изоляция
Нам хотелось бы иметь единый исходный код, который бы компилировался без
изменений во всех системах, но, к сожалению, это может быть нереально. Однако
было бы ошибкой позволить непереносимому коду расползтись по всей программе,
как это и происходит при условной компиляции.
Выносите системные различия в отдельные файлы. Когда для разных систем
требуется разный код, его лучше выносить в отдельные файлы — один файл на
каждую систему. Например, текстовый редактор Sam работает под Unix, Windows и в
ряде других операционных систем. Интерфейсы с системой меняются от среды к
среде очень широко, но большая часть кода Sam везде идентична. Все различия,
связанные с конкретной системой, вынесены в отдельные файлы
: unix. с содержит
код интерфейса с системами Unix, a windows, с — со средой Windows. В этих файлах
реализуются переносимые интерфейсы с операционной системой, различия же
получаются скрытыми. Таким образом, можно сказать, что Sam написан для своей
собственной виртуальной операционной системы, которая переносится на
различные реальные системы с помощью пары сот строк кода на С, реализующих
несколько небольших, но непереносимых операций, вызывающих функции
конкретной системы.
Самое интересное, что графические оболочки различных операционных систем не
играют почти никакого значения
: Sam имеет собственную переносимую библиотеку
для своей графики. Несмотря на то что написать такую библиотеку, конечно же,
гораздо труднее, чем просто адаптировать код под данную систему (код интерфейса
с системой X Window, например, по своим размерам приближается к половине всего
остального ко,ш Sam), суммарные затраты для нескольких систем получаются все
равно меньше. При
этом не надо забывать, что графическая библиотека ценна сама
по себе и использовалась для создания и других переносимых программ.
Sam — это довольно старая программа; в наши дни переносимые графические
оболочки, такие как OpenGL, Tcl/Tk и Java, доступны для большого числа платформ.
Создание кода на их основе вместо использования собственных графических
библиотек обеспечит вашим программам
большую область применения.
Прячьте системные различия за интерфейсами. Абстрагирование — мощный способ
разграничения переносимой и непереносимой частей программы. Хороший тому
пример — библиотеки ввода-вывода, имеющиеся в большинстве языков
программирования: они оперируют абстрактным представлением внешней памяти в
терминах файлов, которые можно открывать, закрывать, читать или записывать, не
затрагивая вопросов их физического расположения или
структуры. Программы,
которые придерживаются этого интерфейса, будут исполняться на любой системе,
где он реализован.
Реализация редактора Sam представляет собой пример абстракции другого рода.
Интерфейс описан для файловой системы и графических операций, а программа
использует только свойства этого интерфейса. Сам интерфейс использует те
возможности, которые имеются в конкретной операционной системе, что приводит
к
появлению абсолютно разных реализаций для разных систем, но программа,
использующая его, зависит только от этого интерфейса, а не от его конкретной
реализации, и поэтому ее не требуется изменять при переносе между системами.
Подход к переносимости, реализованный в системе Java, — пример того, насколько
далеко можно здесь продвинуться. Программа на Java транслируется вЪперации
"
виртуальной машины", модели компьютера, которую можно реализовать на любой
настоящей машине. Библиотеки Java предоставляют унифицированный доступ к
возможностям системы: графике, пользовательскому интерфейсу, сети и т. п.;
библиотеки же отображают этот доступ в возможности локальной системы.
Теоретически должно быть возможно исполнить Java-программу (даже после
трансляции) где угодно без каких-либо изменений.
Обмен данными
Текстовые данные передаются между системами в неизменном виде, | так что это
самый простой и универсальный способ для передачи произ вольной информации
между системами.
Для обмена данными используйте текст. С текстом легко оперировать посредством
множества программ; его можно обрабатывать разными, самыми неожиданными
способами. Например, если вывод одной программы нельзя использовать напрямую
для ввода в другую, то скрипт на Awk или Perl позволяет легко его преобразовать в
нужный вид. С помощью g rep можно производить отбор строк, а ваш любимый
редактор поможет произвести более сложные преобразования. Кроме всего прочего,
I текстовые файлы легко документировать, да и пояснений к
ним требуется гораздо
меньше, потому что их всегда можно прочитать. Комментарий в текстовом файле
может указывать, какая версия программы необ- \ ходима для обработки данных:
например, первая строка файла PostScript определяет версию языка (и, возможно,
тип документа):
%!PS-Adobe-2.0
В противоположность текстовым двоичные файлы требуют для своей j обработки
специализированные средства, и их редко удается
использовать совместно даже на
одной машине. Существует множество известных программ, преобразующих
произвольные двоичные данные в текст. Среди них стоит назвать binhex для
Macintosh, uuencode и uudecode для Unix и различные инструменты, использующие
кодировку MIME для преобразования двоичных данных в почтовые сообщения. В
главе 9 мы расскажем о ряде средств паковки и распаковки двоичных данных для их
передачи
с сохранением переносимости. Кстати, уже само обилие таких
инструментов подчеркивает наличие серьезных проблем, связанных с двоичными
форматами.
С передачей текста связана одна давняя проблема: PC-системы (операционные
системы D'OS и Windows) используют для обозначения конца строки символ
возврата каретки '\r' к символ перевода строки ' \п', а системы Unix — только символ
перевода строки. Возврат каретки — это артефакт
, дошедший до нас от древнего
устройства, называемого телетайпом, который имел операцию возврата каретки
(CR) для возврата печатающего механизма в начало строки и отдельный оператор
протяж-'ки на строку (LF — от Line Feed) для перевода этого механизма на
следующую строку.
Несмотря на то что в современных компьютерах уже нет кареток, которые бы надо
было возвращать
, программное обеспечение для PC, по большей своей части,
продолжает ожидать этой комбинации (известной также как CRLF, произносится
"curliff") в конце каждой строки. Если в файле отсутствуют возвраты каретки, то он
может быть проинтерпретирован как одна гигантская строка, при этом счетчики строк
и символов могут вести себя непредсказуемым образом. Некоторые программы
умеют изящно справляться
с этой проблемой, но таких - меньшинство. Надо сказать,
что PC не единственный виновник подобного безобразия: благодаря
последовательному внедрению требований совместимости некоторые современные
сетевые стандарты, такие как HTTP, также используют CRLF для разделения строк.
Мы можем посоветовать использовать стандартные интерфейсы, которые
воспринимают CRLF в зависимости от конкретной системы -либо (для PC) удаляя
символ \r при вводе и
добавляя его обратно на выходе, либо (для Unix), никогда
даже не создавая его. Для файлов, которые должны будут передаваться туда и
обратно, необходимо написать программу, преобразующую их форматы.
Упражнение 8-2
Напишите программу, которая бы удаляла из файла случайно образовавшиеся
возвраты каретки. После этого напишите еще одну, которая бы добавляла их в
файл, заменяя символы перевода строки комбинацией возврата каретки и перевода
строки. Как вы будете тестировать эти программы?
Порядок байтов
Несмотря на все описанные выше недостатки, иногда двоичные данные
оказываются необходимы. Например, они несравненно более компактны и их
гораздо быстрее декодировать, а эти факторы очень важны для компьютерных
сетей. Но двоичные данные имеют серьезнейшие проблемы с переносимостью.
По крайней мере один вопрос решен: все современные машины имеют 8-битовые
байты. Однако все
объекты, большие байта, представляются на разных машинах по-
разному, поэтому полагаться на какие-то определенные свойства было бы ошибкой.
Короткие целые числа (обычно 16 битов, или 2 байта) могут иметь младший байт,
расположенный как по меньшему адресу (little-endian, младшеконечное
расположение), чем старший, так и по большему (big-endian, старшеконечное)i.
Выбор варианта произволен, а некоторые машины
вообще поддерживают обе!
модели.
Итак, несмотря на то, что и старшеконечные и младшеконечные машины
рассматривают память как последовательность слов, расположенных в одном и том
же порядке, байты внутри слова они интерпретируют! различно. На приведенной
диаграмме четыре байта, начинающиеся с поя зиции 0, представляют
шестнадцатеричное целое 0x11223344 для старшеконечников и 0x44332211 —для
младшеконечников.
Для того чтобы увидеть порядок байтов в действии, запустите следующую
программу:
/* byteorder: отображает байты длинного целого */
int main(void)
{
unsigned long x;
unsigned char *p;
int i;
/* 11 22 33 44 => big-endian */
/* 44 33 22 11 => little-endian */
/* x = Ox1122334455667788UL; для 64-битового long */
x = Ox11223344UL;
p = (unsigned char *) &x;
for (i = 0; i < sizeof(long); i++)
pnntf("%x ", *p++); printf("\n"); return 0; }
На 32-битовом старшеконечнике на экран будет выведено
11 22 33 44
на младшеконечнике —
44 33 22 11
а на PDP-11 (16-битовая машина, все еще встречающаяся во встроенных системах)
результатом будет
22 11 44 33
На машинах с 64-битовым типом long мы можем рассмотреть константу большей
длины и увидеть те же результаты.
Наша программа выглядит довольно глупо, но если нам надо послать целое число
через побайтовый интерфейс, например по сети, то
надо решить, какой байт
посылать первым, а какой вторым, и в этом выборе суть проблемы со старше- и
младшеконечниками. Другими словами, наша программа неявнр выполняет то, что
выражение
fwrite(&x, sizeof(x), 1, stdout);
делает явным образом. Небезопасно писать (отправлять) int (или short, или long) на
одном компьютере и читать это число как int на другом.
Например, если компьютер-передатчик
пишет с помощью
unsigned short x;
fwrite(&x, sizeof(x), 1, stdout);
а компьютер-приемник производит чтение так:
unsigned short x;
fread(&x, sizeof(x), 1, stdin);
то, если эти компьютеры имеют разный порядок байтов, значение х будет
воспроизведено неправильно. Например, если отправлено было число 0x1000, то
прочитано оно будет как 0x0010.
Эта проблема часто решается посредством условной компиляции и перестановки
байтов, то есть примерно так:
? short x;
? fread(&x, sizeof(x), 1, stdin);
? flifdef BIG_ENDIAN
? /*
осуществляем перестановку байтов */
? x = ((x&OxFF) « 8) | ((x»8) & OxFF);
? #endif
При пересылке большого количества двух- и четырехбайтовых целых такой подход
получается слишком громоздким. На практике получает- ; ся, что байты при
пересылке не один раз подвергаются перестановке.
Если ситуация выглядит невесело для short, то для более длинных типов она еще
хуже — для них существует больше способов перепутать байты. А если к этому
добавить
еще всяческие преобразования между членами структур, ограничения на
выравнивание и абсолютно таинственный порядок байтов в старых машинах, то
проблема покажется 4 просто неразрешимой.
Используйте при обмене данными фиксированный порядок байтов.
Решение проблемы все же существует. Записывайте байты в каноническом порядке,
используя переносимый код:
unsigned short x;
putchar(x » 8); /* пишем старший байт */
putchar(x & OxFF); /* пишем младший байт */
и
считывайте их обратно побайтово, собирая первоначальные значения
unsigned
short x;
x = getchar() « 8; /* читаем старший байт */
x |= getchar() & OxFF; /* читаем младший байт */
Этот подход можно перенести и на структуры: записывайте значе-'' ния членов
структур в определенной последовательности, побайтово, без выравнивания.
Неважно, какой порядок байтов вы изберете, — подойдет любой, лишь бы
передатчик и приемник согласовали порядок байтов в
передаче и количество байтов
в каждом объекте. В следующей главе мы покажем несколько инструментов для
упаковки и распаковки данных.
Побайтовая обработка может показаться довольно дорогим удовольствием, но в
сравнении с вводом-выводом, при котором необходима упаковка и распаковка
данных, потери времени окажутся незначительными. Представьте себе систему X
Window, в которой клиент пишет
данные с тем порядком байтов, что используется у
него на машине, а сервер должен распаковывать все, что клиент посылает. На
клиентском конце достигнута экономия в несколько инструкций, но сервер
становится больше и сложнее, поскольку ему приходится обрабатывать
одновременно данные с разными порядками байтов: ведь клиенты вполне могут
иметь различные типы
машин. В общем, сложностей куда больше. Кроме того, не
забывайте, что это графическая оболочка, где расходы на распаковку байтов будут с
лихвой перекрыты выполнением той графической операции, которую они содержат.
Система X Window воспринимает данные от клиента с любым порядком байтов:
считается, что это забота сервера. А система Plan 9, наоборот, сама задает порядок
байтов
для отправки сообщений файл-серверу (или графическому серверу), а
данные запаковываются и распаковываются неким универсальным кодом вроде
приведенного выше. На практике определить временные затраты во время
исполнения оказывается практически невозможно; можно только сказать, что на
фоне ввода-вывода упаковка данных оказывается малозаметной.
Java — язык более высокого уровня, чем С и C++, в
нем порядок байтов скрыт
совсем. Библиотеки представляют интерфейс Serializable, который определяет, как
элементы данных пакуются для передачи.
Однако, если вы пишете на С или C++, всю работу придется выполнять
самостоятельно. Главное, что можно сказать про побайтовую обработку: она решает
имеющуюся проблему для всех машин с 8-битовыми байтами, причем решает без
участия flifdef. Мы еще вернемся к этой теме в следующей главе.
Итак, лучшим решением нередко оказывается преобразование информации в
текстовый
формат, который (не считая проблемы CRLF) является абсолютно
переносимым: не существует никаких неопределенностей с его представлением.
Однако и текстовый формат не является панацеей. Время и размер для некоторых
программ могут быть критичны, кроме того, часть данных, особенно числа с
плавающей точкой, могут потерять точность при округлениях в процессе передачи
через printf и scanf.
Если вам надо передавать числа с плавающей точкой, особо
заботясь о точности, убедитесь, что у вас есть хорошая библиотека
форматированного ввода-вывода; такие библиотеки существуют, просто ее может не
оказаться конкретно в вашей системе. Особенно сложно представлять числа с
плавающей точкой для переноса их в двоичном формате, но при должном внимании
текст может эту проблему решить.
Существует один тонкий момент, связанный с использованием стан-| дартных
функций для обработки двоичных файлов, — эти файлы необходимо открывать в
двоичном режиме:
FILE *fin;
fin = fopen(binary_file, "rb");
с = getc(fin);
Если ' b' опущено, то в большинстве систем Unix это ни на что не повлиЯ яет, но в
системах Windows первый встретившийся во вводе байт 1 Control-Z (восьмеричный
032, шестнадцатеричный 1А) прервет чтение! (такое происходило у нас с
программой st rings из главы 5). В то же вре- j мя при использовании двоичного
режима для чтения текстовых файлов; вам придется вставлять символы \ r во ввод и
убирать их из вывода.
Переносимость и внесение усовершенствований
Одним из наиболее огорчительных источников проблем переносимо-1 сти является
изменение системного программного обеспечения за время жизненного цикла.
Изменения могут затронуть любой интерфейс системы, приводя к неоправданной
несовместимости версий.
При изменении спецификации изменяйте и имя. Наш любимый (если)
можно так выразиться) пример — изменение свойств команды Unix: echo, которая в
изначальном виде предназначалась для простого
вывода аргументов:
% echo hello, world
hello, world
%
Однако со временем эта команда стала ключевой частью многих тов оболочки, и
перед ней встала необходимость генерировать формате рованный вывод. Теперь
echo стала некоторым образом интерпретирс вать аргументы, то есть стала неким
аналогом printf: