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

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

Язык С также является оптимальным для программ, переносимых на многие операционной системы. Однако рассмотренные ниже альтернативы С все больше используются в основных операционных системах, отличных от Unix; в ближайшем будущем значение переносимости как основного преимущества С может уменьшаться.

Иногда преимущество, которое достигается с помощью таких существующих программ, как генераторы синтаксических анализаторов или GUI-построители, которые генерируют код С, так велико, что оправдывает программирование на С остальной части небольшого приложения.

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

В современных условиях, возможно, лучше было бы рассматривать С как ассемблер высокого уровня для виртуальной машины Unix (учебный пример в главе 4). В другие операционные системы C-стандарты внесли такие возможности этой виртуальной машины, как стандартная библиотека ввода-вывода. Язык С незаменим, когда требуется тесная связь с аппаратной составляющей при сохранении переносимости.

Еще одна весомая причина, по которой следует изучать С (даже если требования к языку программирования разработчика удовлетворяются языком более высокого уровня), состоит в том, что это способствует развитию мышления на уровне аппаратной архитектуры. Лучшим справочником и учебным пособием по С для программистов является книга "The С Programming Language" [42].

Перенос C-кода из одного вида операционных систем Unix в другой почти всегда возможен и обычно прост, но в некоторых областях, таких как сигналы и контроль над процессами, могут возникать определенные сложности. Некоторые из этих проблем рассматриваются в главе 17. Различие C-привязок в других операционных системах, несомненно, может вызвать проблемы переносимости С, хотя операционная система Windows NT, по крайней мере, теоретически должна поддерживать ANSI/POSIX-совместимый стандарт С API.

Высококачественные компиляторы С доступны в Internet в виде программ с открытым кодом; наиболее известным и широко применяемым является компилятор С Фонда Свободного программного обеспечения (Free Software Foundation — FSF), входящий в коллекцию компиляторов GNU (GNU Compiler Collection — GCC). Данный компилятор стал базовым для всех Unix-систем с открытым кодом, а также для некоторых систем с закрытым кодом. Версии GCC доступны даже для операционных систем семейства Microsoft. Исходные коды GCC доступны на сайте FSF .

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

14.4.1.1. Учебный пример: fetchmail

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

fetchmail совершает простейшие действия по управлению динамической памятью. Единственная сложная структура данных программы состоит из однонаправленного списка управляющих блоков, по одному на каждый почтовый сервер, который составляется только один раз при запуске и довольно незначительно изменяется впоследствии. Это значительно ослабляет довод против использования С, обходя основной недостаток языка.

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

Наконец, fetchmail нуждается в возможности анализировать довольно сложный синтаксис спецификации для управляющей информации по каждому почтовому серверу. В Unix такая проблема классически решается с помощью генераторов C-кода, вырабатывающих исходный код для лексического и грамматического анализатора из декларативных спецификаций. Существование yacc и lex было доводом в пользу С.

fetchmail можно было бы на приемлемом уровне реализовать на Python, хотя и со значительной потерей производительности. Размер и сложность структуры данных fetchmail полностью исключили бы shell и Tcl и строго указывали бы на недопустимость использования Perl. При этом предметная область программы находится за пределами естественных возможностей Emacs Lisp. Реализация на языке Java не была бы лишена смысла, но объектно-ориентированный стиль и уборка мусора дали бы небольшой выигрыш в специфических проблемах fetchmail по сравнению с теми, которые уже решались с помощью С. С++ так же не смог бы значительно упростить сравнительно простую внутреннюю логику fetchmail.

Однако реальная причина написания fetchmail на С состоит в том, что программа создавалась как постепенное развитие ее предшественника, уже написанного на С. Существующая реализация на С прошла обширное тестирование на разнообразных платформах, на необычных и специфических серверах. Повторная реализация на другом языке была бы сложной и запутанной. Более того, fetchmail зависит от импортируемого кода для функций (таких как NTLM-аутентификация), которые очевидно не доступны на более высоком уровне, чем С.

Интерактивный конфигуратор fetchmail, лишенный традиционной проблемы С, написан на Python; соответствующий учебный пример рассматривается далее.

Когда в середине 1980-х годов С++ был впервые выпущен в свет, объектно- ориентированные языки программирования были широко разрекламированы как радикальное средство против сложности программного обеспечения. Объектно- ориентированные возможности С++ казались бесспорным преимуществом над С, и приверженцы ожидали, что С++ быстро сделает своего предшественника устаревшим.

Этого не случилось. Отчасти причинами могут быть проблемы в самом С++; требование обратной совместимости с С привело ко многим компромиссам в конструкции. Кроме всего прочего, данное требование помешало перевести С++ на полностью автоматическое управление динамической памятью и решить самую серьезную проблему С. Позже "гонка вооружений" между различными разработчиками компиляторов, которую не сдерживала слабая и преждевременная попытка стандартизации, привела к тому, что С++ стал "витиеватым" и чрезвычайно сложным языком.

Причиной послужило также и то, что самой ОО-технологии не удалось оправдать ожидания. Проблема рассматривалась в главе 4 — ОО-методы склонны приводить к созданию больших связующих уровней и проблемам сопровождения. На сегодняшний день, изучение архивов открытого исходного кода (где выбор языка скорее отражает суждения разработчика, чем корпоративные указания) показывает, что использование С++ до сих пор в основном характерно для GUI, мультимедийного инструментария и игр (основных областей успеха ОО-конструкций), и гораздо реже встречается в других областях.

Возможно, что реализация ОО-технологии на С++ особенно склонна к созданию проблем. Существуют данные, которые говорят о том, что расходы на жизненный цикл программ на С++ больше, чем у эквивалентов, написанных на С, FORTRAN или Ada. Является ли данная проблема проблемой ОО, проблемой С++, или это комплексная проблема — пока не ясно, хотя есть смысл подозревать последнее [34].

В последние годы С++ включил в себя некоторые важные не-ОО-идеи. В языке существуют исключения, подобные исключениям в Lisp, т.е. можно добавлять объект или значение в стек вызовов до тех пор, пока его не перехватит обработчик. STL (Standard Template Library, стандартная библиотека шаблонов) обеспечивает типовое программирование, т.е. возможность писать код алгоритмов, независимых от сигнатур их данных, и компилировать их для выполнения необходимых функций во время выполнения. (Это необходимо только для языков, выполняющих статический контроль типов в процессе компиляции; более динамические языки просто передают ссылки на переменные без типа и поддерживают идентификацию типов во время выполнения.)

Эффективный компилируемый язык, совместимость снизу вверх с языком С, объектно-ориентированная платформа, связующий материал для самых современных методик, таких как STL и типовое программирование, — С++ претендует на роль универсального средства, но ценой этого является сложность, гораздо большая, чем та, с которой может справиться мозг отдельного программиста. Как было отмечено в главе 4, главный конструктор языка признал, что он и не ждет, что какой-либо один программист сможет постичь язык полностью. Unix-хакеры не слишком хорошо отреагировали на сложность С++. Подтверждением этого служит одно из анонимных, но известных определений: "С++ — это спрут, полученный путем пришивания лишних ног собаке".

Однако фундаментальная проблема заключается в том, что по существу С++ является просто еще одним традиционным языком. Он лучше сдерживает проблему управления памятью, чем до создания стандартной библиотеки шаблонов (STL), и значительно лучше, чем С. Однако это довольно сомнительное решение проблемы, и оно не будет надежно работать, если в коде не используются объекты и только объекты. Возможности ОО для многих типов приложений незначительны и просто добавляют сложности в С, не достигая весомых преимуществ. Доступны компиляторы С++ с открытым исходным кодом; если бы С++ определенно превосходил С, то в настоящее время он бы доминировал.

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

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

Классическим справочником по С++ является книга Страуструпа (Stroustrup) "The С++ Programming Language" [82]. Отличными учебным пособием по С++ и основным ОО-методам для начинающих является книга "С++: A Dialog" [36]. Статья "С++ Annotations" [6] представляет собой сжатый вводный курс по С++ для опытных программистов на С.

Компилятор С++ входит в состав коллекции компиляторов GNU. Поэтому, язык доступен как для Unix, так и для операционных систем Microsoft; в данном случае также применимы комментарии, касающиеся С. Доступна обширная коллекция вспомогательных библиотек с открытым исходным кодом . Однако переносимость языка ограничена тем, что (в середине 2003 года) в действующих реализациях С++ реализованы значительно отличающиеся подмножества проектного ISO-стандарта, который в настоящий момент находится в процессе подготовки[120].

14.4.2.1. С++ учебный пример: инструментарий Qt

Интерфейсный инструментарий Qt представляет собой замечательный пример успеха С++ в современном мире программ с открытым исходным кодом. Инструментарий предоставляет комплект элементов управления, а также API для написания графических пользовательских интерфейсов для системы X Window, который был сознательно (и довольно эффективно) разработан таким образом, чтобы имитировать вид и восприятие интерфейсов Motif, MacOS Platinum или Microsoft Windows. Фактически Qt предоставляет гораздо больше, чем просто GUI-службы, — он предоставляет переносимый прикладной уровень с классами для XML, доступа к файлам, сокетов, параллельных процессов, таймеров, обработки даты и времени, доступа к базам данных, различных абстрактных типов данных и Unicode.

Инструментарий Qt является важным и видимым компонентом проекта KDE, старейшего из двух конкурирующих проектов с открытым исходным кодом по разработке GUI и интегрированного набора настольных приложений.

Реализация Qt на С++ демонстрирует преимущества ОО-языка программирования для инкапсуляции компонентов пользовательского интерфейса. В языке, поддерживающем объекты, видимая иерархия элементов управления интерфейса может быть четко выражена с помощью иерархии экземпляров классов в коде программы. Несмотря на то, что то же самое можно сымитировать в С с помощью явного преобразования через созданную вручную таблицу методов, код, написанный на С++, будет гораздо чище. Полезно сравнить его с известным своей причудливостью С API в Motif.

Исходный код и справочная документация по Qt доступна на сайте Trolltech .

Первым (и долгое время единственным) переносимым интерпретируемым языком был 'Bourne shell' (sh) 7 версии Unix. В настоящий момент родоначальный Bourne shell в значительной степени вытеснили разновидности совместимого снизу вверх Korn Shell (ksh). Единственным наиболее важным из них является Bourne Again Shell (bash).

Существуют и согласованно используются несколько других видов shell, но как языки программирования они не столь значительны. Наиболее известным из них, вероятно, является С shell (csh), печально известный своей непригодностью для написания сценариев[121].

Элементарные shell-программы чрезвычайно просты и естественны в написании. Язык shell послужил началом Unix-традиции быстрого создания прототипов на интерпретируемых языках.

Однако по мере увеличения своего размера, shell-программы часто становятся скорее узкоспециальными. Некоторые моменты синтаксиса shell (особенно правила использования кавычек и синтаксис операторов) могут сбить с толку. Данные недостатки, как правило, обусловлены компромиссами в той части конструкции shell, которая связана с языком программирования. Эти компромиссы были внесены, для того чтобы сохранить эффективность shell как интерактивного интерпретатора командной строки.

Программы описывают как "shell-программы" даже если они не написаны исключительно на shell, но в них интенсивно используются С-фильтры, такие как sort(1), и стандартные мини-языки обработки текста, такие как sed(1) или awk(1). Однако данный вид программирования в течение нескольких лет идет на убыль. В наши дни подобная сложная связующая логика обычно пишется на Perl или Python, a shell резервируется для простейших упаковщиков (для которых данные языки были бы чрезмерно сложными) и сценариев инициализации системы (которая не предполагает, что они доступны).

Базовое shell-программирование достаточно описано в любой вводной книге по Unix. "The Unix Programming Environment" [39] остается одним из лучших источников для программистов среднего и высокого класса. Реализации или клоны Korn shell представлены в каждой Unix-системе.

Сложные shell-сценарии часто имеют проблемы переносимости не столько из-за самой оболочки, а ввиду сделанных в них предположений о доступности той или иной программы в качестве компонента. Несмотря на то, что в отдельных случаях клоны bash и ksh доступны в операционных системах, отличных от Unix, shell-программы (практически) вообще невозможно перенести за пределы Unix.

В завершение отметим, что лучшее качество shell — естественность и быстрота написания небольших сценариев. Худшей стороной shell является то, что крупные shell- сценарии зависят от множества вспомогательных команд, которые вовсе не обязательно идентично ведут себя и даже не всегда присутствуют на всех целевых машинах. Кроме того, анализировать зависимости в крупных shell-сценариях также непросто.

Почти никогда не возникает необходимость компилировать или устанавливать shell, поскольку все Unix-системы и эмуляторы Unix поставляются с подобными оболочками. Стандартной оболочкой для Linux и других передовых вариантов Unix в настоящее время является bash.

14.4.3.1. Учебный пример:

xmlto

xmlto — управляющий сценарий, который вызывает все команды, необходимые для представления какого-либо XML-DocBook-документа в виде HTML, PostScript, простого текста или любого другого доступного формата (более подробно DocBook рассматривается в главе 18). Сценарий

xmlto

bash

Детали вызова XSLT-процессора обрабатываются в xmlto с помощью соответствующей таблицы стилей, затем результаты передаются постпроцессору. Для HTML и XHTML вся обработка сводится к трансформации. Для получения простого текста XML также трансформируется в HTML, а затем передается постпроцессору — lynx(1) в режиме

-dump

xmlto

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

Программа

xmlto

Теоретически данный сценарий можно было бы выполнить на любой системе, поддерживающей

bash

14.4.3.2. Учебный пример: Sorcery Linux

Sorcerer GNU/Linux — дистрибутив Linux, устанавливаемый как небольшая, загрузочная опорная система, мощность которой достаточна для работы bash(1) и нескольких утилит загрузки данных. Имея этот код, можно вызвать Sorcery, систему пакетов Sorcerer.

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

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

Perl — shell на стероидах. Данный язык был специально предназначен для замены awk(1) и расширен, чтобы заменить shell в качестве уровня, связывающего сценарии, написанные на нескольких языках. Первая версия Perl вышла в 1987 году.

Самым сильным качеством Perl являются его чрезвычайно мощные встроенные средства для шаблонной обработки текстовых, строковых форматов данных, и в этой области Perl является непревзойденным. Данный язык также включает в себя гораздо более прочные структуры данных, чем shell, включая динамические массивы элементов различных типов, а также тип "hash" или "dictionary", который поддерживает удобный и быстрый поиск пар имя-значение.

Дополнительно Perl включает в себя довольно полную и хорошо продуманную привязку практически всего API-интерфейса Unix, что радикально уменьшает потребность в С и делает Perl пригодным для таких задач, как простые TCP/IP-клиенты и даже серверы. Другим серьезным преимуществом Perl является то, что вокруг него сформировалось крупное и жизнеспособное сообщество открытого исходного кода. Центром данного сообщества в сети является ресурс Comprehensive Perl Archive Network (обширны архив Perl-программ) . Преданные Perl-хакеры создали сотни свободно используемых Perl-модулей для множества различных задач программирования. В число данных модулей входит структурный обход дерева каталогов, X-инструментарий для создания GUI-интерфейсов, превосходные встроенные средства для поддержки HTTP-роботов и CGI-программирования.

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

Наиболее полным справочником по Perl является книга "Programming Perl" [88]. В ней содержится почти вся необходимая информация по данному языку, однако книга печально известна своей плохой организацией; чтобы найти необходимые сведения, читателю приходится перерабатывать множество материала. Более упорядоченным источником является книга "Learning Perl" [76].

Язык Perl универсален в Unix-системах. Perl-сценарии с одинаковым основным номером версии часто легко переносимы между Unix-системами (при условии, что в них не используются модули расширения). Реализации Perl доступны (и даже хорошо документированы) для операционных систем семейства Microsoft, а также MacOS. Perl/Tk обеспечивает кроссплатформенную GUI-совместимость.

Выводы: наибольшим преимуществом Perl является мощный аппарат для мелких связующих сценариев, включающих большой объем обработки регулярных выражений; наибольшим недостатком данного языка является то, что он уродлив, "несговорчив" и в больших объемах почти не поддерживается.

14.4.4.1. Небольшой учебный пример по Perl:

blq

blq

blg

blq

blq

blq

$0=~s!.*/!!;

blq

14.4.4.2. Большой учебный пример по Perl:

keeper

Программа

keeper

keeper

keeper

Tcl (Tool Command Language — язык инструментальных команд) — небольшой языковой интерпретатор, предназначенный для связи с компилируемыми C-библиотеками и обеспечивающий управление C-кодом с помощью сценариев (extended scripts — расширенные сценарии). Первоначально он применялся для управления библиотеками для электронных симуляторов (SPICE-подобных приложений). Tcl также подходит для встроенных сценариев (embedded scripts), т.е. сценариев, которые вызываются из C-программ и возвращают им значения. Первая общедоступная версия Tcl вышла в 1990 году.

Некоторые средства, созданные на основе Tcl, широко используются за пределами Tcl-сообщества. Ниже описываются два наиболее важных из них.

• Инструментарий Tk, более податливый и легкий X-интерфейс, который упрощает быстрое создание кнопок, диалоговых окон, меню и полос прокрутки текста, а также собирает входные данные от них.

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

Инструментарий Tk настолько важен, что язык часто называется Tcl/Tk. Tk также часто используется с языками Perl или Python.

Главным преимуществом языка Tcl является то, что он чрезвычайно гибок и в своей основе прост. Его синтаксис необычен (основывается на позиционном анализаторе), но полностью последователен. В языке отсутствуют зарезервированные слова, а также синтаксическое различие между вызовом функции и "встроенным" синтаксисом. Таким образом, можно из Tcl эффективно переопределить собственно языковой интерпретатор (что делает рациональными проекты, подобные

Expect

Основным недостатком Tcl является то, что чистый язык имеет только слабые средства для управления пространством имен и модульностью, а два из них (

upvar

uplevel

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

Чистый Tcl предоставляет доступ только к сравнительно небольшой и широко используемой части Unix API (по существу, только обработка файлов, создание подпроцессов и сокетов). Действительно, Tcl интересен как демонстрация того, каким небольшим и вместе с тем полезным может быть язык сценариев. Tcl-расширения (подобно модулям Perl) обеспечивают более развитый набор возможностей, однако (как и в случае CPAN-модулей) нет гарантии, что они установлены везде.

Оригинальным справочником по Tcl является книга "Tcl and the Tk Toolkit" [58], но ее уже почти "затмила" книга "Practical Programming in Tcl and Tk" [89]. Брайан Керниган создал описание реального Tcl-проекта [38], в котором показаны преимущества и недостатки Tcl как инструмента быстрого создания прототипов и реальных программ. Его противопоставление Microsoft Visual BASIC особенно взвешенно и поучительно.

Сообщество Tcl не имеет одного центрального репозитария, поддерживаемого основной группой, аналогичной группам поклонников языка Perl или Python, но несколько выдающихся Web-сайтов ссылаются друг на друга и описывают большую часть разработки Tcl-инструментов и расширений. Прежде всего, стоит обратить внимание на проект Tcl Developer Xchange ; среди прочего он предоставляет Tcl-код интерактивного учебного пособия по Tcl. Кроме того, существует лаборатория Tcl на сайте SourceForge .

Tcl-сценарии имеют проблемы переносимости, аналогичные проблемам сценариев shell. Сам язык хорошо переносим на другие платформы, но компоненты, которые он вызывает, могут не быть таковыми. Существуют реализации Tcl для операционных систем семейства Microsoft, MacOS и многих других платформ. Tcl/Tk-сценарии будут работать на любой платформе, обладающей возможностями поддержки GUI-интерфейса.

Выводы: сильной стороной Tcl является его экономная, компактная конструкция и расширяемость Tcl-интерпретатора; худшей стороной языка является необычный позиционный синтаксический анализатор, слабость структур данных и управления пространством имен. Последний дефект делает язык слабо масштабируемым для больших проектов.

14.4.5.1. Учебный пример: TkMan

TkMan — браузер для man-страниц Unix и документов Texinfo. Исходный код состоит примерно из 1200 строк, что довольно много для программы, написанной на чистом Tcl, но код необычайно хорошо организован и разделен на модули. Для создания GUI-интерфейса, несколько лучшего, чем интерфейс, поддерживаемый стандартными утилитами man(1) или xman(1), используется инструментарий Tk.

TkMan представляет собой хороший учебный пример, поскольку он демонстрирует почти полную гамму технических приемов Tcl. В число наиболее ярких входит Tk-интеграция, управление другими Unix-приложениями (такими как поисковая машина Glimpse) с помощью сценариев, а также использование Tcl для синтаксического анализа Texinfo-разметки.

Любой другой язык не предоставил бы настолько прямой интерфейс к Tk GUI, который составляет большую часть данного кода.

Исходный код и документацию можно найти в Web с помощью ключевого слова "TkMan".

14.4.5.2. Moodss: большой учебный пример по Tcl

Система Moodss представляет собой графическое мониторинговое приложения для системных администраторов. Оно способно следить за журналами и накапливать статистические данные по работе MySQL, Linux, SNMP-сетей и Apache, а также предоставляет их систематизированный обзор посредством GUI-панелей, которые имеют вид электронных таблиц и называются инструментальными панелями (dashboards). Модули мониторинга могут быть написаны на Python или Perl, а также на Tcl. Код безукоризненно написан, организован и считается примером для подражания в Tcl-сообществе. Существует Web-сайт проекта — .

Ядро программы состоит из 18 000 строк Tcl-кода. В нем используется несколько Tcl-расширений, включая специальную объектную систему. Автор Moodss признает, что без них "написание такого большого приложения было бы невозможным".

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

Python является языком написания сценариев, предназначенным для тесной интеграции с С. Он способен как импортировать, так и экспортировать данные в динамически загружаемые С-библиотеки, его также можно вызывать из С как встроенный язык сценариев. Синтаксис Python очень напоминает гибрид синтаксиса С и семейства Modula, но имеет ту необычную особенность, что структура блока фактически определяется отступами (в языке нет аналогов явных директив begin/end или фигурных скобок С). Первая публичная версия Python вышла в 1991 году.

Язык Python представляет собой очень четкую, элегантную конструкцию с превосходными свойствами модульности. Он предоставляет разработчикам возможность писать программы в объектно-ориентированном стиле, но не вынуждает делать этого (возможно программирование более традиционным, процедурным способом, подобным С). Язык имеет систему типов, сравнимую по выразительности с системой типов Perl, включая динамические контейнеры и ассоциативные списки, но менее характерную (документально подтвержден тот факт, что объектная система Perl была создана как подражание системе Python). Данный язык устраивает даже Lisp-хакеров, предоставляя безымянные лямбда-операторы (задаваемые функциями объекты, которые могут распространяться и использоваться итераторами). Python поставляется с Tk-инструментарием, который можно использовать для простого создания GUI-интерфейсов.

Стандартный дистрибутив Python включает в себя клиентские классы для большинства важных Internet-протоколов (SMTP, FTP, POP3, IMAP, HTTP) и порождающие классы для HTML. Поэтому рассматриваемый язык хорошо подходит для протокольных роботов и каналов сетевого администрирования. Он также превосходно подходит для работы в Web CGI и успешно конкурирует с Perl на участке высокой сложности в данной прикладной области.

Из всех рассматриваемых интерпретируемых языков Python и Java являются двумя наиболее точно подходящими для масштабирования в большие сложные проекты с множеством взаимодействующих разработчиков. Во многом Python проще, чем Java, и его предрасположенность к быстрому созданию прототипов может дать ему преимущество перед Java для автономного использования в приложениях, которые не являются ни чрезмерно сложными, ни требующими высокой скорости выполнения. Реализация Python на языке Java, предназначенная для облегчения смешанного использования обоих языков, доступна и используется в реальных проектах. Она называется Jython.

Python не может конкурировать с С или С++ по скорости выполнения (хотя использование стратегии смешанных языков на сегодняшних быстрых процессорах, возможно, делает этот недостаток сравнительно второстепенным). Фактически Python, как правило, считается наименее эффективным и самым медленным из основных языков сценариев — это цена, которую приходится платить за полиморфизм типов во время выполнения. Однако не стоит по этой причине отказываться от использования данного языка. Большинству приложений фактически не требуется производительность, большая, чем предоставляется Python. Приложения, в которых такая производительность действительно необходима, обычно ограничены внешними задержками, такими как задержки сети или дисков. Кроме того, в виде компенсации, Python исключительно просто комбинируется с С, поэтому для достижения существенного прироста скорости чувствительные к производительности Python-модули можно легко преобразовывать в С.

Python проигрывает в выразительности языку Perl для небольших проектов и связующих сценариев, сильно зависящих от возможностей обработки регулярных выражений. Данный язык был бы избыточным в мелких проектах, для которых более подходящим может быть shell или Tcl.

Как и Perl, Python имеет хорошо организованное сообщество разработчиков с центральным Web-сайтом , содержащим множество полезных реализаций Python, инструментов и модулей расширения.

Наиболее полным справочником по языку Python является книга "Programming Python" [51]. Обширная документация по Python-расширениям также доступна на Web-сайте проекта Python.

Python-программы в большинстве случаев хорошо переносятся между Unix-системами и даже на другие операционные системы. Стандартная библиотека достаточно мощная для того, чтобы значительно сократить использование непереносимых вспомогательных программ. Реализации Python доступны для операционных систем Microsoft и MacOS. Кроссплатформенная разработка GUI возможна с помощью либо Tk, либо двух других инструментариев. Python/C-приложения могут быть "замороженными", квази-скомпилированными в чистый исходный код С, который должен быть переносимым на системы без установленного Python.

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

14.4.6.1. Небольшой учебный пример по Python:

imgsizer

Imgsizer — утилита, которая переписывает WWW-страницы так, что теги включения изображений автоматически получают верные размеры изображения (это ускоряет загрузку страниц во многих браузерах). Исходные коды и документацию можно найти в подкаталоге "URL WWW tools" архива ibiblio.

Программа imgsizer первоначально была написана на Perl, и была почти идеальным примером небольшого, управляемого шаблонами инструмента обработки текста. Позднее программа была транслирована в Python в целях получения преимущества библиотеки Python по поддержке HTTP-передачи. В результате этого зависимость от внешней утилиты доставки страницы была устранена. Примечательно использование утилит file(1) и identify(1) пакета ImageMagick в качестве специальных средств для получения размеров изображений в пикселях.

Динамическая обработка строк и необходимость замысловатой проверки регулярных выражений сделала бы написание imgsizer на С или С++ крайне сложным. Такая версия также была бы значительно больше и сложнее для чтения. Язык Java решил бы проблему неявного управления памятью, но он едва ли был бы более выразительным, чем С или С++ при проверке текстовых шаблонов.

14.4.6.2. Учебный пример по Python среднего размера: fetchmailconf

В главе 11 пара fetchmail/fetchmailconf рассматривалась как пример одного из способов отделения реализации от интерфейса. Преимущества Python хорошо иллюстрируются на примере утилиты fetchmailconf.

В программе fetchmailconf используется инструментарий Tk для реализации многопанельного редактора конфигурации с графическим интерфейсом (для GTK также существуют Python-привязки и другие инструментарии, но Tk-привязки поставляются с каждым интерпретатором Python).

В режиме для высококвалифицированных пользователей GUI-интерфейс поддерживает редактирование около 60 атрибутов, распределенных по трем уровням панелей. Элементы управления атрибутами включают в себя комбинацию из флажков, переключателей, текстовых полей и списков. Несмотря на эти сложности, автору книги потребовалось меньше недели, включая четыре дня на изучение Python и Tk, для проектирования и кодирования первой полнофункциональной версии.

Python превосходит другие языки в быстром создании прототипов GUI-интерфейсов, а (как показывает пример fetchmailconf) прототипы часто являются основными составляющими реальных проектов. Perl и Tcl имеют аналогичные сильные стороны в данной области (включая инструментарий Tk, который был написан для Tcl), но они сложнее в управлении на уровне сложности кода fetchmailconf (приблизительно 1400 строк). Emacs Lisp не подходит для GUI-программирования.

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

14.4.6.3. Большой учебный пример Python: PIL

Python-библиотека обработки графики (Python Imaging Library — PIL) поддерживает обработку растровой графики. Программа поддерживает множество популярных форматов, включая PNG, JPEG, BMP, TIFF, PPM, XBM и GIF. Python-программы могут использовать ее для того, чтобы конвертировать и трансформировать изображения. В число поддерживаемых трансформаций входит кадрирование, вращение, масштабирование и сдвиг. Также поддерживается пиксельное редактирование, искривление изображений и преобразования цветов. Дистрибутив PIL включает в себя Python-программы, которые делают доступными данные средства из командной строки. Таким образом, программу PIL можно использовать для трансформации изображений в пакетном режиме или в качестве мощного инструментария, посредством которого реализуется программируемая обработка растровых изображений.

Реализация PIL иллюстрирует способ, который позволяет легко расширять Python с помощью загружаемых расширений Python-интерпретатора, состоящих из объектного кода. Код библиотеки, реализующей основные операции над растровыми объектами, написан на С для обеспечения скорости. Более высокие уровни и программная логика, написанные на Python, работают медленнее, но проще для чтения, модификации и расширения.

Было бы сложно или даже невозможно написать аналогичный инструментарий на Emacs Lisp или shell, которые вообще не имеют или не документируют интерфейс C-расширений. Tcl имеет хорошие средства C-расширений, но программа PIL была бы неудобно большим проектом на Tcl. Подобные средства имеются в Perl (Perl XSO), но они представляют собой узкоспециальные решения, слабо документированы, сложны и нестабильны по сравнению со средствами Python, а также используются редко. Интерфейс машинно-зависимых методов в Java (Native Method Interface), вероятно, обеспечивает возможности, сравнимые с возможностями Python. Было бы, вероятно, рационально создать проект PIL на Java.

Код программы PIL и документация доступны на Web-сайте проекта .

Язык программирования Java был разработан под девизом "написанное однажды работает везде" и предназначен для поддержки встроенных интерактивных программ (или аплетов) на Web-страницах, которые запускались бы из любого браузера. Благодаря серии грубых технических и стратегических просчетов правообладателя, корпорации Sun Microsystems, данный язык потерпел неудачу в достижении обеих первоначальных целей. Однако Java до сих пор достаточно силен как в системном, так и в прикладном программировании, чтобы составить конкуренцию С и С++. Язык Java был анонсирован в 1995 году.

Язык Java талантливо спроектирован для использования больших преимуществ автоматического управления памятью и меньших, но не менее важных, преимуществ

поддержки ОО-конструкции, будучи при этом меньше по размеру и сложности, чем С++. В данном языке заметно сохранен С-подобный синтаксис, который удобен большинству программистов. Java включает в себя поддержку внешних вызовов к динамически загружаемому С и вызовов Java как встроенного языка из С. Не случайно, что Sun выполнила большую работу по созданию хорошей документации по Java, доступной в Web.

Недостатком Java можно считать то, что (по сравнению, например, с Python) некоторые части языка представляются чрезмерно сложными, а другие неразвиты. Видимость классов Java и правила явного определения блоков являются вычурными. Такие функции, как внутренние и неименованные классы, могут привести к очень запутанному коду. Отсутствие надежных методов деструкторов означает, что трудно гарантировать соответствующее управление другими ресурсами, кроме памяти, например, мьютексами и блокировкой файлов. Значительная часть средств операционной системы Unix, включая сигналы, опрос и выбор, не доступна из Java в стандартной поставке. Несмотря на то, что в Java имеются очень мощные I/O-средства, простое чтение текстовых файлов затруднено.

Наблюдается и сложная проблема с библиотеками, подобная "аду DLL" в Windows. В Java отсутствует метод для управления различными версиями библиотек, что может привести к возникновению крупных проблем в таких средах, как серверы приложений, где сервер может поставляться с одной версией (например) XML-библиотеки, а приложение с другой (обычно более новой) версией. Единственной возможностью решения таких проблем является переменная среды

CLASSPATH

Более того, Sun неразумно управляет Java как с политической, так и с технической точки зрения. Первый GUI-инструментарий Java, AWT был неорганизованной смесью, которую необходимо было в корне заменить. Отказ от стандартизации ECMA/ISO еще больше раздражал разработчиков, уже расстроенных положениями SCSL (Sun Community Source License — лицензия на исходный код в сообществе Sun). Ограничения данного документа препятствуют реализациям Java 1.2 с открытым исходным кодом и их спецификациям J2EE (Java 2 Enterprise Edition). Это дискредитирует исходные цели универсальной переносимости Java.

К сожалению, аплеты браузеров мертвы. Фактически их уничтожило решение Microsoft не поддерживать Java 1.2 в Internet Explorer. Однако язык Java, вероятно, нашел гарантированную нишу в экологии вычислений — "сервлеты", работающие внутри серверов Web-приложений. Java также все чаще используется для многих внутри корпоративных программных разработок, не связанных непосредственно с базами данных или Web-серверами. Данный язык становится главным конкурентом как для платформы Microsoft ASP/COM, так и для Perl CGI. Наконец, Java широко распространен и все больше используется как язык для обучающего, вводного программирования (роль, для которой он чрезвычайно хорошо подходит).

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

Как Java достигнет равновесия с другими рассмотренными здесь языками до сих пор не ясно и может сильно зависеть от масштаба проекта. Можно ожидать, что соответствующая Java ниша будет подобна нише Python. Как и Python, Java не может конкурировать ни с С или С++ в отношении чистой скорости выполнения, ни с Perl в мелких проектах, где интенсивно используется шаблонное редактирование. Данный язык (более явно, чем Python) является избыточным для мелких проектов. Можно предположить, что Python получит преимущество в мелких проектах, a Java в более крупных, но окончательный результат будет ясен позднее.

Лучшим печатным справочником, вероятно, является книга "Java In A Nutshell" [19], она, однако, не является лучшим учебным пособием. Таким, вероятно, можно считать книгу "Thinking in Java" [17]. Ссылки на все мировые Web-сайты, посвященные Java, начинаются с сайта Java Sun , на котором также представлена полная HTML-документация, доступная для бесплатной загрузки. Полезные ссылки по Java также собраны на сайте проекта Open Directory Java Page .

Реализации Java доступны для всех Unix-систем, операционных систем Microsoft, MacOS и многих других платформ.

Исходные коды Kaffe, открытой реализации Java, в которой библиотеки классов согласуются с большей частью JDK 1.1 и частично с JDK 1.2, доступны на сайте проекта Kaffe .

Существует Java-интерфейс для GCC. Программа GCJ способна компилировать Java-код либо в Java-байткод, либо в собственный код, а также Java-байткод — в собственный код. Данный компилятор поставляется в пакете с открытыми библиотеками классов, реализующими большую часть JDK 1.2, и интерпретатором Java-байткода, который называется gij. Подробности описаны на странице проекта GCJ .

Существует Java IDE-среда для Emacs, см. сайт проекта JDEE .

Java прекрасно переносится между платформами на уровне языка. Проблема может возникнуть из-за несовершенных реализаций библиотек (особенно ранних версий JDK 1.1, которые не поддерживают более новый пакет JDK 1.2).

Наилучшим качеством Java является то, что данный язык достаточно плотно приблизился к идеалу "написанное однажды работает везде", для того чтобы быть полезным в качестве независимой от операционной системы среды. Наибольший недостаток Java заключается в том, что дробление Java 1/Java 2 подрывает эту цель, глубоко разочаровывая разработчиков.

14.4.7.1. Учебный пример: FreeNet

Freenet — одноранговый сетевой проект, цель которого заключается в том, чтобы сделать невозможной цензуру и подавление информационного наполнения Web-страниц[122]. Разработчики Freenet предвидят несколько видов использования проекта.

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

• Эффективное распространение информационного наполнения, требующего большой полосы пропускания: адаптивное кэширование и зеркала используются для распространения программных обновлений Debian Linux.

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

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

Язык Java был хорошим выбором для данного проекта, как минимум, по двум причинам. Во-первых: цели проекта серьезно оценивают совместимые реализации на самых разнообразных машинах, поэтому высокая переносимость Java является главным преимуществом. Во-вторых: природа проекта такова, что важным является сетевой API-интерфейс, a Java имеет мощный встроенный API.

Язык С является традиционным для инфраструктурных проектов такого рода, которые имеют высокие требования к производительности, но недостаток стандартизированного сетевого API значительно затруднил бы переносимость. Такие же трудности возникли бы и в случае использования С++. Языки Tсl, Perl или Python могли бы сократить нагрузку переносимости, но ценой больших потерь в производительности. Emacs Lisp был бы крайне медленным и совершенно несоответствующим.

Программы yacc и lex являются инструментальными средствами для генерации синтаксических анализаторов языков программирования. В главе 8 отмечалось, что свой первый мини-язык программист часто создает случайно, а не как часть запланированной конструкции. В результате, как правило, появляется созданный вручную синтаксический анализатор, который приводит к чрезмерным затратам времени на сопровождение и отладку, особенно, если разработчик не поймет, что часть разработанного им кода является синтаксическим анализатором и не отделит его соответствующим образом от остальной части кода приложения. Генераторы синтаксических анализаторов являются инструментами, которые позволяют добиться большего, чем создание случайной, узкоспециальной реализации. Они не только позволяют разработчику выразить спецификацию грамматики на более высоком уровне, но и четко отделяют сложность реализации синтаксического анализатора от остального кода.

Если разработчик достиг того момента, когда планируется реализовать мини- язык с нуля, а не путем расширения или внедрения существующего языка сценариев или анализатора XML, то утилиты yacc и lex, вероятно, окажутся наиболее важными инструментами после компилятора С.

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

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

Утилита yacc имеет довольно некрасивый интерфейс — через экспортируемые глобальные переменные с именным префиксом

yy_

Программа lex — генератор лексических анализаторов. Она входит в состав того же функционального семейства, что и grep(1) и awk(1), но является более мощной, поскольку позволяет подготовить произвольный С-код для выполнения при каждом совпадении. Программа принимает декларативный мини-язык и создает "скелетный" С-код.

Для того чтобы понять работу lex-сгенерированного анализатора лексем, существует грубый, но удобный способ — мысленная инверсия работы grep(1). Тогда как grep(1) принимает одно регулярное выражение и возвращает список совпадений во входном потоке данных, каждый вызов lex-сгенерированного анализатора лексем принимает список регулярных выражений и указывает, какое выражение встречается следующим в потоке данных.

Утилита lex была написана для автоматизации создания лексических анализаторов (анализаторов лексем) для компиляторов. Впоследствии оказалось, что она имеет удивительно широкий диапазон применения для других видов распознавания образцов, и с тех пор описывается как "швейцарский нож Unix-программирования"[125].

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

Важнее то, что мини-язык lex-спецификации является более высокоуровневым и компактным, чем эквивалентный С-код, написанный вручную. Доступны модули для использования flex (версия с открытым исходным кодом) с Perl (их можно найти в Web с помощью фразы "lex perl"), а также идентично работающая реализация, которая является частью средства PLY в Python.

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

Утилита yacc — генератор синтаксических анализаторов. Она также была написана для автоматизации части работы по написанию компиляторов, yacc принимает на входе грамматическую спецификацию в декларативном мини-языке, подобном BNF (Backus-Naur Form — запись Бэкуса-Наура), с С-кодом, связанным с каждым элементом грамматики. Данная программа генерирует код для функции синтаксического анализа, которая при вызове принимает текст, соответствующий грамматике из входного потока. По мере распознавания каждого грамматического элемента, функция анализатора запускает связанный С-код.

Комбинация утилит lex и yacc весьма эффективна для написания языковых интерпретаторов всех видов. Хотя большинству Unix-программистов никогда не придется выполнять данный вид универсального построения компилятора, для которого задумывались эти инструменты, они чрезвычайно полезны для написания анализаторов синтаксиса конфигурационных файлов и узкоспециальных мини-языков.

Сгенерированные с помощью lex анализаторы лексем работают очень быстро при распознавании низкоуровневых образцов во входных потоках, однако известный утилите lex язык регулярных выражений плохо подходит для вычисления или распознавания рекурсивно вложенных структур. Для их анализа потребуется yacc. С другой стороны, несмотря на то, что теоретически возможно написать yacc-грамматику с собственным сбором лексем, такая грамматика была бы перегружена кодом, а анализатор был бы крайне медленным. Для анализа входных лексем следует использовать lex. Таким образом, данные инструменты являются симбиотическими.

Если существует возможность реализовать анализатор на языке более высокого уровня, чем С (что и рекомендуется; см. главу 14), то следует рассмотреть такие

эквивалентные средства, как PLY в Python (которое охватывает функции lex и yacc)[126] или Perl-модули PY и Parse::Yapp, либо Java-пакеты CUP[127], Jack[128] или Yacc/M[129].

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

#line

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

15.3.1.1. Учебный пример: грамматика

fetchmailrc

Канонический демонстрационный пример, который, видимо, приводится в каждом учебном пособии по lex и yacc, представляет собой игрушечную программу интерактивного калькулятора, которая анализирует и вычисляет введенные пользователем арифметические выражения. В данной книге нет этого избитого клише. Заинтересованные читатели могут обратиться к исходному коду реализации bc(1) и dc(1) проекта GNU или к принципиальному примеру "hoc"[130] см. [39].

Вместо этого грамматика анализатора конфигурационных файлов fetchmail предоставляет хороший учебный пример среднего размера по использованию lex и yacc. Здесь имеется несколько интересных моментов.

lex-спецификация в файле

rcfile_l.l

yacc-спецификация в файле

rcfile_y.y

Программа make может оказаться полезной не только для программ на C/C++. Языки сценариев, подобные описанным в главе 14, могут не требовать традиционных этапов компиляции и компоновки, однако часто существуют другие виды зависимостей, с которыми поможет справиться утилита make(1).

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

Весьма распространенной является практика использования правил make-файлов в целях выражения инструкций для создания документации, так же как и кода. Часто такой подход используется для автоматического создания PostScript или другой производной документации из главных документов, написанных на каком-либо языке разметки (например, HTML или одном из языков создания документов в Unix, которые рассматриваются в главе 18). Фактически такое использование настолько широко распространено, что его стоит проиллюстрировать учебным примером.

15.4.2.1. Учебный пример: использование make для преобразования файла документации

В make-файле программы fetchmail, например, есть три правила, которые связывают файлы FAQ, FEATURES и NOTES с исходными HTML-файлами

fetchmail-FAQ.html

fetchmail-features.html

design-notes.html

HTML-файлы предназначены для просмотра на Web-странице программы fetchmail, но если Web-браузер не используется, то HTML-разметка делает эти файлы неудобными для просмотра. Поэтому

FAQ

FEATURES

NOTES

Простые текстовые формы могут быть получены из главных HTML-файлов с помощью распространенной программы lynx(1) с открытым исходным кодом. lynx — является Web-браузером для текстовых дисплеев. Однако если данную программу вызвать с параметром -dump, то она будет достаточно корректно функционировать в качестве преобразователя HTML-ASCII.

Правила make позволяют разработчику редактировать главные HTML-документы, не заботясь впоследствии о повторной ручной сборке простых текстовых форм, поскольку файлы

FAQ

FEATURES

NOTES

Одним из неочевидных преимуществ Unix make по сравнению с базами данных зависимостей, встроенных в многие IDE-среды, является то, что make-файлы представляют собой простые текстовые файлы, т.е. файлы, которые могут создаваться программами.

В середине 1980-х годов в дистрибутивах крупных Unix-программ были достаточно распространены сложные специальные shell-сценарии, которые исследовали окружение и использовали собранную информацию для создания нестандартных make-файлов. Такие специальные конфигураторы достигали абсурдных размеров. Автор данной книги однажды написал такой конфигуратор, состоящий из 3000 строк shell-кода, почти вдвое больше любого отдельного модуля программы, для которой он был предназначен, и это не было необычным.

Однажды было решено положить этому конец, и многие представители сообщества настроились на написание инструментов, которые автоматизировали бы часть или весь процесс сопровождения make-файлов. Данные инструментальные средства обычно были призваны разрешить две проблемы.

Одной из проблем была переносимость на другие платформы. Генераторы make-файлов в большинстве случаев создаются для работы на множестве различных аппаратных платформ и вариантов Unix. Как правило, они пытаются определить параметры локальной системы (включая все от размера машинного слова до инструментов, языков служебных библиотек и даже имеющихся в системе программ форматирования документов). Затем генераторы пытаются использовать полученные сведения для написания make-файлов, которые используют средства локальной системы и компенсируют ее индивидуальные особенности.

Другой проблемой является вывод зависимостей. Существует возможность получить множество сведений о зависимостях в семействе файлов исходного C-кода путем анализа самих файлов (особенно их директив

#include

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

15.4.4.1. makedepend

Несколько небольших инструментов решают исключительно часть описанной выше проблемы, связанную с автоматизацией правил. Утилита makedepend, распространяемая наряду с системой X Window разработки MIT, является самым быстрым и наиболее полезным из таких инструментов и предустанавливается на все современные Unix-системы, включая все дистрибутивы Linux.

makedepend принимает коллекцию исходных кодов С и генерирует зависимости для соответствующих

.о

#include

makedepend бесполезна для проектов, написанных не на С. Утилита не пытается решать несколько частей проблемы создания make-файлов. Однако то, что она делает, она делает особенно хорошо.

Утилита makedepend полностью документирована на соответствующей странице руководства. Команда

man makedepend

15.4.4.2. Imake

Утилита Imake была написана в попытке автоматизировать создание make-файлов для системы X Window. Она надстраивается на makedepend для решения как проблемы вывода зависимостей, так и проблемы переносимости.

Imake-система эффективно заменяет традиционные make-файлы Imake-файлами, написанными в более компактной и мощной форме, которая (эффективно) компилируется в make-файлы. В процессе компиляции используется файл правил, который считается специфическим для системы и включает в себя множество сведений о локальной среде.

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

Imake-инструменты доступны на любой Unix-системе, поддерживающей X, включая Linux. Существует один "героический" проект [16], цель которого заключается в "прояснении тайн" Imake для не X-программистов. Вопросы, освещаемые данным проектом, стоит изучить всем, кто собирается заниматься X-программированием.

15.4.4.3. autoconf

Утилита autoconf была написана программистами, которые изучили и отклонили подход Imake. Утилита autoconf генерирует для каждого проекта shell-сценарии

configure

configure

Утилита autoconf направлена на разрешение проблемы переносимости и вообще не выполняет встроенного вывода зависимостей. Несмотря на то, что данная программа, вероятно, такая же сложная, как Imake, она является гораздо более гибкой и проще расширяется. Вместо использования базы данных правил в системе, утилита генерирует shell-код configure, который осматривает систему, определяя необходимые параметры.

Каждый

configure

configure.in

configure

Подход к созданию make-файлов, принятый для autoconf, подобен подходу Imake в том, что разработчик начинает с написания шаблона make-файла для своего проекта. Однако файлы

Makefile.in

Утилита autoconf документирована в руководстве в GNU info-формате. Исходные сценарии autoconf доступны на сайте архива FSF, а кроме того, они предустановлены на многих Unix и Linux-системах. Упомянутое руководство можно просматривать с помощью справочной системы Emacs.

Несмотря на отсутствие непосредственной поддержки вывода зависимостей и характерного для autoconf узкоспециального подхода, в середине 2003 года данная утилита, несомненно, была наиболее популярной из всех генераторов make-файлов. Она превзошла Imake и стала причиной выхода из употребления, по крайней мере, одного главного конкурента (metaconfig).

Существует справочник "GNU Autoconf Automake and Libtool" [86]. Дополнительная информация по утилите autoconf в несколько ином аспекте рассматривается в главе 17.

15.4.4.4. automake

Утилита automake — это попытка добавить Imake-подобную функцию вывода зависимостей как уровень над autoconf(1). Разработчик пишет шаблоны

Makefile.am

Makefile.in

configure

automake в середине 2003 года все еще оставалась сравнительно новой технологией. Она используется в нескольких FSF-проектах, но еще не принята широко за пределами FSF-сообщества. Несмотря на то, что ее общий подход выглядит многообещающе, утилита все еще является довольно хрупкой — она работает в стереотипных условиях, но склонна к серьезным сбоям, если попытаться использовать ее необычным путем.

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

15.5.4.1. Source Code Control System (SCCS)

Первой из рассматриваемых систем появилась SCCS, оригинальная система управления исходным кодом (Source Code Control System), разработанная в Bell Labs примерно в 1980 году и представленная в System III Unix. SCCS — это, вероятно, первая серьезная попытка создания унифицированной системы управления исходным кодом. Передовые идеи, впервые реализованные в ней, до сих пор встречаются на некотором уровне во всех последующих системах, включая коммерческие Unix- и Windows-продукты, такие как ClearCase.

Однако сама SCCS в настоящее время устарела. Она была частной собственностью Bell Labs. С тех пор были разработаны превосходные альтернативы с открытыми исходными кодами, и большая часть Unix-сообщества перешла к их использованию. SCCS до сих пор используется некоторыми коммерческими поставщиками программного обеспечения для управления старыми проектами, однако для новых проектов ее рекомендовать нельзя.

Не существует ни одной реализации SCCS с полностью открытым исходным кодом. Клон, который называется CSSC (Compatibly Stupid Source Control), разрабатывается при поддержке FSF.

15.5.4.2. Revision Control System (RCS)

Список превосходных альтернатив с открытым исходным кодом начинается с системы RCS (Revision Control System — система управления ревизиями), которая была создана в Университете Пурдью через несколько лет после SCCS и первоначально распространялась с 4.3BSD Unix. Данная система логически подобна SCCS, но имеет более четкий командный интерфейс и хорошие средства для группировки целых редакций проекта под символическими именами.

RCS в настоящее время является наиболее широко используемой системой в мире Unix. В некоторых других Unix-системах контроля версий RCS используется в качестве серверной части или базового уровня. Она хорошо подходит для проектов, разрабатываемых одним разработчиком или небольшой группой разработчиков, находящихся в одной лаборатории.

Исходные коды RCS курируются и распространяются FSF. Существуют бесплатные версии для операционных систем Microsoft и VAX VMS.

15.5.4.3. Concurrent Version System (CVS)

CVS (Concurrent Version System — система параллельных версий) была разработана в начале 1990-х годов как клиентская часть к RCS, но модель контроля версий, которая использовалась в ней, настолько отличалась, что данная система была немедленно квалифицирована как новая конструкция. Современные реализации не основываются на RCS.

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

Интерфейс CVS значительно более сложен, чем интерфейс RCS, и требует большего дискового пространства. Данные свойства делают систему неудачным выбором для небольших проектов. С другой стороны, CVS хорошо подходит для крупных проектов с участием множества разработчиков, распространенных по нескольким участкам разработки, которые связаны друг с другом посредством Internet. CVS-инструменты на клиентской машине можно легко настроить на непосредственное взаимодействие с репозиторием, расположенным на другом узле.

В сообществе открытого исходного кода система CVS интенсивно используется для таких проектов, как GNOME и Mozilla. Обычно такие CVS-репозитории позволяют любому разработчику отмечать исходные файлы удаленно. Следовательно, кто угодно может создать локальную копию проекта, модифицировать ее и отправить заплаты с изменениями по почте кураторам проекта. Реальный доступ на запись к такому репозиторию более ограничен и должен быть явно предоставлен кураторами проекта. Разработчик, имеющий такой доступ, может обновить проект из своей модифицированной локальной копии, в результате чего локальные изменения вносятся непосредственно в удаленный репозиторий.

Пример хорошо организованного CVS-репозитория, доступного через Internet, можно посмотреть на сайте GNOME CVS . На сайте иллюстрируется использование инструментов быстрого просмотра с поддержкой CVS, таких как Bonsai, которые полезны тем, что способствуют координации работы крупной и децентрализованной группы разработчиков.

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

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

Исходные коды системы CVS сопровождаются и распространяются FSF.

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

15.5.4.4. Другие системы контроля версий

Конструктивные проблемы системы CVS достаточны для того, чтобы создать потребность в лучших VCS-системах с открытым исходным кодом. Несколько таких проектов полным ходом разрабатывались в 2003 году. Наиболее выдающимися из них являются проекты Aegis и Subversion.

Проект Aegis имеет самую длинную историю среди CVS-альтернатив и является зрелой действующей системой. С 1991 года данная система обеспечивает контроль версий для самого проекта Aegis. Особый акцент в этой системе сделан на возвратное тестирование и проверку достоверности.

Система Subversion позиционируется как "правильно сделанная CVS", с полностью разрешенными известными конструктивными проблемами. В 2003 году данная система имела наилучшие перспективы заменить в ближайшем будущем CVS.

Проект BitKeeper исследует некоторые интересные конструктивные идеи, связанные с группами изменений и множественными распределенными репозиториями кода. Линус Торвальдс использует Bitkeeper для исходных кодов ядра Linux. Однако лицензия (отличная от лицензий на открытый исходный код) на данную систему является спорной и значительно задерживает признание данного продукта сообществом.