4.3 Заголовочные Файлы

Типы во всех описаниях одного и того же объекта должны быть согласованными. Один из способов это достичь мог бы сос­тоять в обеспечении средств проверки типов в компоновщике, но большинство компоновщиков - образца 1950-х, и их нельзя изме­нить по практическим соображениям*. Другой подход состоит в обеспечении того, что исходный текст, как он передается на рассмотрение компилятору, или согласован, или содержит инфор­мацию, которая позволяет компилятору обнаружить несогласован­ности. Один несовершенный, но простой способ достичь согласо­ванности состоит во включении заголовочных файлов, содержащих интерфейсную информацию, в исходные файлы, в которых содер­жится исполняемый код и/или определения данных.

--------------------

* Легко изменить один компоновщик, но сделав это и напи­сав программу, которая зависит от усовершенствований, как вы будете переносить эту программу в другое место? (прим. авто­ра)

Механизм включения с помощью #include - это чрезвычайно простое средство обработки текста для сборки кусков исходной программы в одну единицу (файл) для ее компиляции. Директива

#include "to_be_included"

замещает строку, в которой встретилось #include, содер­жимым файла "to_be_included". Его содержимым должен быть ис­ходный текст на С++, поскольку дальше его будет читать компи­лятор. Часто включение обрабатывается отдельной программой, называемой C препроцессором, которую команда CC вызывает для преобразования исходного файла, который дал программист, в файл без директив включения перед тем, как начать собственно компиляцию. В другом варианте эти директивы обрабатывает ин­терфейсная система компилятора по мере того, как они встреча­ются в исходном тексте. Если программист хочет посмотреть на результат директив включения, можно воспользоваться командой

CC -E file.c

для препроцессирования файла file.c точно также, как это сделала бы CC перед запуском собственно компилятора. Для включения файлов из стандартной директории включения вместо кавычек используются угловые скобки < и >. Например:

#include <stream.h> //из стандартной директории включения

#define "myheader.h" // из текущей директории

Использование <> имеет то преимущество, что в программу фактическое имя директории включения не встраивается (как правило, сначала просматривается /usr/include/CC, а потом usr /include). К сожалению, пробелы в директиве include сущест­венны:

#include < stream.h > // не найдет <stream.h>

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

Следующее эмпирическое правило относительно того, что следует, а что не следует помещать в заголовочные файлы, яв­ляется не требованием языка, а просто предложением по разум­ному использованию аппарата #include.

В заголовочном файле могут содержаться:

Определения типов struct point (* int x, y; *)

Описания функций extern int strlen(const char*); Определения inline-функ-й inline char get()(*return *p++;*)

Описания данных extern int a;

Определения констант const float pi = 3.141593

Перечисления enum bool (* false, true *);

Директивы include #include <signal.h>

Определения макросов #define Case break;case

Комментарии /* проверка на конец файла */

но никогда:

Определения обычных функций char get() (* return *p++; *)

Определения данных int a;

Определения сложных константных объектов const tbl[]=(*/*

... */ *)

В системе UNIX принято, что заголовочные файлы имеют суффикс (расширение) .h. Файлы, содержащие определение данных или функций, должны иметь суффикс .c. Такие файлы часто назы­вают, соответственно, ".h файлы" и ".c файлы". В #4.7 описы­ваются макросы. Следует заметить, что в С++ макросы гораздо менее полезны, чем в C, поскольку С++ имеет такие языковые конструкции, как const для определения констант и inline для исключения расходов на вызов функции.

Причина того, почему в заголовочных файлах допускается определение простых констант, но не допускается определение сложных константных объектов, прагматическая. В принципе, сложность тут только в том, чтобы сделать допустимым дублиро­вание определений переменных (даже определения функций можно было бы дублировать). Однако для компоновщиков старого образ­ца слишком трудно проверять тождественность нетривиальных констант и убирать ненужные повторы. Кроме того, простые слу­чаи гораздо более обиходны и потому более важны для генерации хорошего кода.