Интерфейс синтаксического анализатора совершенно прозрчен: // syn.c: описания для синтаксического анализа и вычисления

extern double expr(); extern double term();

extern double prim();

// syn.c: определения для синтаксического анализа и // вычисления

#include «error.h» #include «lex.h» #include «syn.h»

double prim() (* /* ... */ *) double term() (* /* ... */ *) double expr() (* /* ... */ *)

Главная программа, как всегда, тривиальна:

// main.c: главная программа

#include «stream.h» #include «error.h» #include «lex.h» #include «syn.h» #include «table.h» #include «string.h»

main(int argc, char* argv[]) (* /* ... */ *)

Сколько заголовочных файлов использовать в программе, зависит от многих факторов. Многие из этих факторов сильнее связаны с тем, как ваша система работает с заголовочными фалами, нежели с С++. Например, если в вашем редакторе нет средств, позволяющих одновременно видеть несколько файлов, использование большого числа файлов становится менее привлкательным. Аналогично, если открывание и чтение 10 файлов по 50 строк в каждом требует заметно больше времени, чем чтение одного файла в 500 строк, вы можете дважды подумать, прежде чем использовать в небольшом проекте стиль множественных зголовочных файлов. Слово предостережения: набор из десяти зголовочных файлов плюс стандартные заголовочные файлы обычно легче поддаются управлению. С другой стороны, если вы разбили описания в большой программе на логически минимальные по рамеру заголовочные файлы (помещая каждое описание структуры в свой отдельный файл и т.д.), у вас легко может получиться нразбериха из сотен файлов.

4.3.3 Сокрытие данных

Используя заголовочные файлы пользователь может опредлять явный интерфейс, чтобы обеспечить согласованное исползование типов в программе. С другой стороны, пользователь может обойти интерфейс, задаваемый заголовочным файлом, вводя в .c файлы описания extern.

Заметьте, что такой стиль компоновки не рекомендуется:

// file1.c: // «extern» не используется int a = 7; const c = 8; void f(long) (* /* ... */ *)

// file2.c: // «extern» в .c файле extern int a; extern const c; extern f(int); int g() (* return f(a+c); *)

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

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

// table.c: определения таблицы имен

#include «error.h» #include «string.h» #include «table.h»

const TBLSZ = 23; static name* table[TBLSZ];

name* look(char* p; int ins) (* /* ... */ *)

Это гарантирует, что любой доступ к table действительно будет осуществляться именно через look(). «Прятать» константу TBLSZ не обязательно.

4.4 Файлы как модули

В предыдущем разделе .c и .h файлы вместе определяли часть программы. Файл .h является интерфейсом, который ипользуют другие части программы, .c файл задает реализацию. Такой объект часто называют модулем. Доступными делаются только те имена, которые необходимо знать пользователю, отальные скрыты. Это качество часто называют сокрытием данных, хотя данные – лишь часть того, что может быть скрыто. Модули такого вида обеспечивают большую гибкость. Например, реализция может состоять из одного или более .c файлов, и в виде .h файлов может быть предоставлено несколько интерфейсов. Инфомация, которую пользователю знать не обязательно, искусно скрыта в .c файлах. Если важно, что пользователь не должен точно знать, что содержится в .c файлах, не надо делать их доступными в исходом виде. Достаточно эквивалентных им выхоных файлов компилятора (.o файлов).

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

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

Каждый статически размещенный объект по умолчанию иницализируется нулем, программист может задать другие (константные) значения. Это только самый примитивный вид инциализации. К счастью, с помощью классов можно задать код, который выполняется для инициализации перед тем, как модуль какимлибо образом используется, и/или код, который запускаеся для очистки после последнего использования модуля, см. #5.5.2.

4.5 Как создать библиотеку

Фразы типа «помещен в библиотеку» и «ищется в какой-то библиотеке» используются часто (и в этой книге, и в других), но что это означает для С++ программы? К сожалению, ответ звисит от того, какая операционная система используется; в этом разделе объясняется, как создать библиотеку в 8-ой весии системы UNIX. Другие системы предоставляют аналогичные возможности.

Библиотека в своей основе является множеством .o файлов, полученных в результате компиляции соответствующего множества .c файлов. Обычно имеется один или более .h файлов, в которых содержатся описания для использования этих .o файлов. В кчестве примера рассмотрим случай, когда нам надо задать (обычным способом) набор математических функций для некоторго неопределенного множества пользователей. Заголовочный файл мог бы выглядеть примерно так:

extern double sqrt(double); // подмножество «math.h» extern double sin(double); extern double cos(double); extern double exp(double); extern double log(double);

а определения этих функций хранились бы, соответственно, в файлах sqrt.c, sin.c, cos.c, exp.c и log.c.

Библиотеку с именем math.h можно создать, например, так:

$ CC -c sqrt.c sin.c cos.c exp.c log.c $ ar cr math.a sqrt.o sin.o cos.o exp.o log.o $ ranlib math.a

Вначале исходные файлы компилируются в эквивалентные им объектные файлы. Затем используется команда ar, чтобы создать архив с именем math.a. И, наконец, этот архив индексируется для ускорения доступа. Если в вашей системе нет ranlib комады, значит она вам, вероятно, не понадобится. Подробности посмотрите, пожалуйста, в вашем руководстве в разделе под зголовком ar. Использовать библиотеку можно, например, так:

$ CC myprog.c math.a

Теперь разберемся, в чем же преимущества использования math.a перед просто непосредственным использованием .o фалов? Например:

$ CC myprog.c sqrt.o sin.o cos.o exp.o log.o

Для большинства программ определить правильный набор .o файлов, несомненно, непросто. В приведенном выше примере они включались все, но если функции в myprog.c вызывают только функции sqrt() и cos(), то кажется, что будет достаточно

$ CC myprog.c sqrt.o cos.o

Но это не так, поскольку cos.c использует sin.c.

Компоновщик, вызываемый командой CC для обработки .a файла (в данном случае, файла math.a) знает, как из того мнжества, которое использовалось для создания .a файла, извлечь только необходимые .o файлы.

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

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