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

Заметьте, что описания функций работы со строками теперь включаются из «string.h». Это исключает еще один возможный источник ошибок.

// lex.h: описания для ввода и лексического анализа

enum token_value (* NAME, NUMBER, END, PLUS='+', MINUS='-', MUL='*', DIV='/', PRINT=';', ASSIGN='=', LP='(', RP=')' *);

extern token_value curr_tok; extern double number_value; extern char name_string[256];

extern token_value get_token;

Этот интерфейс лексического анализатора достаточно бепорядочен. Недостаток в надлежащем типе лексемы обнаруживает себя в необходимости давать пользователю get_token фактческие лексические буферы number_value и name_string.

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

#include «stream.h» #include «ctype.h» #include «error.h» #include «lex.h»

token_value curr_tok; double number_value; char name_string[256];

token_value get_token (* /* ... */ *)

Интерфейс синтаксического анализатора совершенно прозрчен: // 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 файлов).