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). В таком случае текст каждой единицы трансляции может начинаться тысячами строк заголовочных файлов. Содержимое заголовочных файлов библиотеки, как правило, стабильно и меняется редко. Здесь очень пригодился бы претранслятор, который обрабатывает его. По сути, нужен язык специального назначения со своим транслятором. Но устоявшихся методов построения такого претранслятора пока нет.

4.3.2 Множественные заголовочные файлы

Разбиение программы в расчете на один заголовочный файл больше подходит для небольших программ, отдельные части которых не имеют самостоятельного назначения. Для таких программ допустимо, что по заголовочному файлу нельзя определить, чьи описания там находятся и по какой причине. Здесь могут помочь только комментарии. Возможно альтернативное решение: пусть каждая часть программы имеет свой заголовочный файл, в котором определяются средства, предоставляемые другим частям. Теперь для каждого файла .c будет свой файл .h, определяющий, что может предоставить первый. Каждый файл .c будет включать как свой файл .h, так и некоторые другие файлы .h, исходя из своих потребностей.

Попробуем использовать такую организацию программы для калькулятора. Заметим, что функция error() нужна практически во всех функциях программы, а сама использует только <iostream.h>. Такая ситуация типична для функций, обрабатывающих ошибки. Следует отделить ее от файла main.c:

error.h: обработка ошибок

extern int no of errors;

extern double error(const char* s);

error.c

#include <iostream.h> #include error.h int no of errors;

syn.c: определения для синтаксического анализа и вычислений #include error.h #include lex.h

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

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

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

table.h: описание таблицы имен 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); }

table.h: определение таблицы имен #include error.h #include <string.h> #include table.h const int TBLSZ = 23; name* table[TBLSZ];

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

Заметьте, что теперь описания строковых функций берутся из включаемого файла <string.h>. Тем самым удален еще один источник ошибок.

lex.h: описания для ввода и лексического анализа enum token value {

NAME, NUMBER, END,

PLUS=+, MINUS=-, MUL=*,

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 <iostream.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.h: описания для синтаксического анализа и вычислений extern double expr(); extern double term(); extern double prim();

#include syn.h

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

Как обычно, определение основной программы тривиально:

main.c: основная программа #include <iostream.h> #include error.h #include lex.h #include syn.h #include table.h

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

Какое число заголовочных файлов следует использовать для данной программы зависит от многих факторов. Большинство их определяется способом обработки файлов именно в вашей системе, а не собственно в С++. Например, если ваш редактор не может работать одновременно с несколькими файлами, диалоговая обработка нескольких заголовочных файлов затрудняется. Другой пример: может оказаться, что открытие и чтение 1 0 файлов по 50 строк каждый занимает существенно больше времени, чем открытие и чтение одного файла из 500 строк. В результате придется хорошенько подумать, прежде чем разбивать небольшую программу, используя множественные заголовочные файлы. Предостережение: обычно можно управиться с множеством, состоящим примерно из 1 0 заголовочных файлов (плюс стандартные заголовочные файлы). Если же вы будете разбивать программу на минимальные логические единицы с заголовочными файлами (например, создавая для каждой структуры свой заголовочный файл), то можете очень легко получить неуправляемое множество из сотен заголовочных файлов.

4.4 Связывание с программами на других языках

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

extern C char* strcpy(char*, const char*); Результат этого описания отличается от результата обычного описания

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

только порядком связывания для вызывающих strcpy() функций. Сама семантика вызова и, в частности, контроль фактических параметров будут одинаковы в обоих случаях. Описание extern C имеет смысл использовать еще и потому, что языки С и С++, как и их реализации, близки друг другу. Отметим, что в описании extern C упоминание С относится к порядку связывания, а не к языку, и часто такое описание используют для связи с Фортраном или ассемблером. Эти языки в определенной степени подчиняются порядку связывания для С.

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

extern C {

char* strcpy(char*, const char); int strcmp(const char*, const char*) int strlen(const char*)