Искусство программирования для Unix - Эрик Реймонд

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 — весьма типичная реализация shell-подобного синтаксиса. Обратите внимание на то, как два дополняющих правила поддерживают строки либо с одинарными, либо с двойными кавычками; данная идея хороша в принципе. Правила для принятия (возможно, со знаком) целых литералов и отклонения комментариев также являются достаточно распространенными.

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

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

Программа Glade рассматривалась в главе 8 в качестве хорошего примера декларативного мини-языка. Также отмечалось, что в результате работы серверной части Glade генерируется код на одном из нескольких языков.

Glade представляет собой хороший современный пример генератора прикладного кода. Описанные ниже функции, которые отсутствуют в большинстве GUI-построителей (особенно в большинстве коммерческих GUI-построителей), делают Glade. Unix-программой "по духу".

• Glade GUI и генератор кода Glade не связаны в массивном монолите, а подчиняются правилу разделения (и построены согласно модели "разделения ядра и интерфейса").

• GUI и генератор кода соединяются с помощью текстового формата (основанного на XML), который можно читать и модифицировать с помощью других инструментов.

• Поддерживается несколько целевых языков (а не только С или С++). Существует возможность легко добавлять другие языки.

Конструкция позволяет при необходимости заменить редактор GUI-интерфейса в Glade.

15.4. Утилита make: автоматизация процедур

Сами по себе исходные коды программ не делают приложения. Также важен способ их компоновки и упаковки для распространения. Операционная система Unix предоставляет инструментальное средство для частичной автоматизации данных процессов — make(1). Утилита make описывается в большинстве вводных книг по операционной системе Unix. Более конкретная ссылка приводится в книге "Managing Projects tenth Make" [57]. В случае использования GNU make (наиболее развитого варианта make, который обычно поставляется в составе Unix-систем с открытым исходным кодом) рецепты книги "Programming with GNU Software" [50] могут в некотором отношении оказаться лучшими. Большинство Unix-систем, содержащих GNU make, также поддерживают GNU Emacs. В таких системах, вероятно, полное руководство по make можно обнаружить в info-системе документации Emacs.

На сайте FSF доступны версии GNU make для DOS и Windows.

15.4.1. Базовая теория make

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

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

Например, программист может указать в make-файле, что бинарный файл myprog зависит от трех объектных файлов myprog.о, helper.о и stuff.о. Если имеются файлы исходного кода myprog.с, helper.с и stuff.с, то утилита make без специальных указаний определит, что каждый .о-файл зависит от соответствующего .с-файла, и предоставит собственную стандартную инструкцию для сборки .о-файла из .с-файла.

Возникновение make связано с визитом ко мне Стива Джонсона (Steve Johnson — автор yacc и других программ). Когда он пришел, он был очень недоволен тем, что ему пришлось потратить впустую утро, занимаясь отладкой корректной программы (ошибка была устранена, файл не был откомпилирован, и, следовательно, cc *.о не работала). А поскольку я потратил часть предыдущего вечера, справляясь с той же проблемой в разрабатываемом мною проекте, у нас появилась идея создания инструмента для решения данной задачи. Все началось с тщательно продуманной идеи анализатора зависимостей, потом свелось к нечто более простому и в те же выходные превратилось в make. Использование инструментов, которые все еще оставались сырыми, было частью культуры. Make-файлы были текстовыми, а не "волшебно" закодированными бинарными файлами, поскольку это было в духе Unix: печатаемый, отлаживаемый, понятный материал.