4.3.1 Единственный заголовочный файл

Проще всего разбить программу на несколько файлов следующим

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

число входных файлов, а все типы, необходимые для связи между

ними, описать в единственном заголовочном файле. Все входные

файлы будут включать заголовочный файл. Программу

калькулятора можно разбить на четыре входных файла .c:

lex.c, syn.c, table.c и main.c. Заголовочный файл dc.h будет

содержать описания каждого имени, которое используется более

чем в одном .c файле:

// dc.h: общее описание для калькулятора

#include <iostream.h>

enum token_value {

NAME, NUMBER, END,

PLUS='+', MINUS='-', MUL='*', DIV='/',

PRINT=';', ASSIGN='=', LP='(', RP=')'

};

extern int no_of_errors;

extern double error(const char* s);

extern token_value get_token();

extern token_value curr_tok;

extern double number_value;

extern char name_string[256];

extern double expr();

extern double term();

extern double prim();

struct name {

char* string;

name* next;

double value;

};

extern name* look(const char* p, int ins = 0);

inline name* insert(const char* s) { return look(s,1); }

Если не приводить сами операторы, lex.c должен иметь такой вид:

// lex.c: ввод и лексический анализ

#include "dc.h"

#include <ctype.h>

token_value curr_tok;

double number_value;

char name_string[256];

token_value get_token() { /* ... */ }

Используя составленный заголовочный файл, мы добьемся,

что описание каждого объекта, введенного пользователем, обязательно

окажется в том файле, где этот объект определяется. Действительно,

при обработке файла lex.c транслятор столкнется с описаниями

extern token_value get_token();

// ...

token_value get_token() { /* ... */ }

Это позволит транслятору обнаружить любое расхождение в типах,

указанных при описании данного имени. Например, если бы функция

get_token() была описана с типом token_value, но определена с

типом int, трансляция файла lex.c выявила бы ошибку: несоответствие

типа.

Файл syn.c может иметь такой вид:

// syn.c: синтаксический анализ и вычисления

#include "dc.h"

double prim() { /* ... */ }

double term() { /* ... */ }

double expr() { /* ... */ }

Файл table.c может иметь такой вид:

// table.c: таблица имен и функция поиска

#include "dc.h"

extern char* strcmp(const char*, const char*);

extern char* strcpy(char*, const char*);

extern int strlen(const char*);

const int TBLSZ = 23;

name* table[TBLSZ];

name* look(char* p, int ins) { /* ... */ }

Отметим, что раз строковые функции описаны в самом файле table.c,

транслятор не может проверить согласованность этих описаний по типам.

Всегда лучше включить соответствующий заголовочный файл,

чем описывать в файле .c некоторое имя как extern. Это может

привести к включению "слишком многого", но такое включение нестрашно,

поскольку не влияет на скорость выполнения программы и ее размер, а

программисту позволяет сэкономить время. Допустим, функция strlen() снова

описывается в приведенном ниже файле main.c. Это только лишний

ввод символов и потенциальный источник ошибок, т.к. транслятор

не сможет обнаружить расхождения в двух описаниях strlen() (впрочем,

это может сделать редактор связей). Такой проблемы не возникло бы,

если бы в файле dc.h содержались все описания extern, как первоначально

и предполагалось. Подобная небрежность присутствует в нашем примере,

поскольку она типична для программ на С. Она очень естественна

для программиста, но часто приводит к ошибкам и таким программам,

которые трудно сопровождать. Итак, предупреждение сделано!

Наконец, приведем файл main.c:

// main.c: инициализация, основной цикл, обработка ошибок

#include "dc.h"

double error(char* s) { /* ... */ }

extern int strlen(const char*);

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

В одном важном случае заголовочные файлы вызывают большое неудобство.

С помощью серии заголовочных файлов и стандартной

библиотеки расширяют возможности языка, вводя множество типов (как

общих, так и рассчитанных на конкретные приложения; см. главы 5-9).

В таком случае текст каждой единицы трансляции может начинаться

тысячами строк заголовочных файлов. Содержимое заголовочных

файлов библиотеки, как правило, стабильно и меняется редко. Здесь

очень пригодился бы претранслятор, который обрабатывает его. По сути,

нужен язык специального назначения со своим транслятором. Но устоявшихся

методов построения такого претранслятора пока нет.