Бьерн Страуструп. Язык программирования С++. Специальное издание (2011) (1004033), страница 57
Текст из файла (страница 57)
й" №Ыс1ийе на«1 ег. й" Реализация лексического анализатора кроме заголовка 1ехег.№г зависит еще от егтог. №г, <1ол№геагл>, йтгег. В и от функций, определяющих тип символов, объявленных в <сс!уре>: Глава 9. Исходные файлы и программы Ипс1иае «озп еа<п> Ипс1и«е <сс<рре> телег:: Тойеп га<ие Телег«сигг <ой< попые Аехег: <питое< га!ие; зЫ:: з<г<пд Сехег".: з<г<пд га<ие < йехег:: То«еп га!ие Т.ехег«де« ойеп () (/* ...
*/) Можно было бы выделить директиву №1пс№и<№е "еггог. й" в отдельный файл с суффиксом ипр1.Ь, но я счел это излишним для столь малой программы. Как всегда, мы включаем файл с пользовательским интерфейсом модуля— в данном случае файл 1ехег. Ь, в файл реализации модуля, чтобы дать компилятору возможность проверить согласованность типов.
Причина, по которой мы вводим в программу файл <№г№зег. й, заключается в том, что функции Хехег::яе« о!<ел () нужен доступ к средствам ввода: // файл Й.1гег.№п па<пезрасе Вг<гег ( йи по о~' еггогю зЫ:: 1з<геат* тры< пой< зй<р () / ) Таблица символов вполне самодостаточна, и стандартный заголовок <тар> содержит все необходимое для ее эффективной реализации (в виде экземпляра шаблонного класса <пар): // файл <аЫе.№п №1пс1и«е «пар> №<пс!и<ге <з<г<пд> ех<егп з«<: < тар<зЫ:: з<г(пд, аоиЫе> <аЫе< Поскольку каждый заголовочный файл может включаться в разные .
с файлы, то нужно отделить объявление <аЫе от ее определения: // файл <аЫе.с: Ипс!и«е "<аЫе. 1<" зи(:: тар<зЫ:: з<г(пе, аоиЫе> <аЫе< По существу, управляющая программа зависит ото всего: // файл та<п.с: №<пс<и«е "роте<. 1<" Ипс<иае "1ехег. 1<" №1пс<и<(е "еггог.<<" Иле<и«е "<аЫе. 1<" Ипс1ийе "«<<ге<. 1<" №1пс<и«е <зз<геат> <п< тат (<п<агдс, сваг* агяг[) ) (/*...*/) 9.3. Применяем заголовочные файлы 273 Для больших программ стоило бы реорганизовать структуру программы так, чтобы ее управляющая часть имела бы меньше прямых зависимостей.
Часто также желательно минимизировать и код функции агагаО, поместив в нее лишь вызов управляющей функции, размещенной в своем собственном модуле. Это особенно важно для библиотечного кода, ибо тогда мы не можем полагаться на ага(а() и должны быть готовы к тому, что вызовы могут последовать из самых разных функций 59.6[8[). 9.3.2.2. Использование заголовочных файлов Оптимальное для данной программы количество используемых заголовочных файлов зависит от многих факторов.
Многие из этих факторов относятся даже не к языку С++, а к тому, как ведется работа с файлами в вашей системе. Например, если ваш редактор не допускает удобной параллельной работы со множеством файлов, то большое количество заголовочных файлов становится определенным препятствием в работе. Или, если ваш редактор на открытие и просмотр двадцати файлов по пятьдесят строк каждый требует больше времени, чем на ту же работу с единственным файлом из 1000 строк, то тут уж дважды подумаешь, прежде чем решишься применить схему организации небольшой программы в варианте со многими заголовками. Предупредим, что дюжина собственных плюс ряд стандартных для конкретной реализации заголовков (могут исчисляться сотнями) вполне терпимы. Однако если вы сегментируете объявления в большой программе на логически минимальные заголовки (содержащие, например, объявление единственной структуры), то можете столкнуться с хаосом из сотен файлов даже для небольших проектов.
Я нахожу это излишним. Для больших проектов множественные заголовочные файлы неизбежны. В таких проектах сотни собственных (не считая стандартных) заголовков являются нормой. Настоящая проблема начинается, когда их число переваливает за тысячу. В масштабе таких проектов обсуждаемые здесь методики по-прежнему применимы, но это уже задача для Геракла. Запомните, что для настоящих больших программ единственный заголовочный файл — зто не актуально. В них всегда присутствует много заголовочных файлов. Реальный выбор между двумя стилями организации заголовков переносится на меньшие части проектов. На самом деле, обсуждаемые здесь два стиля организации заголовочных файлов вовсе не альтернативны друг другу. Скорее, они являются комплиментарными технологиями, выбор между которыми всегда стоит при разработке важных модулей, и вопрос о таком выборе возникает снова и снова по мере эволюции программной системы.
Важно понимать, что один и тот же интерфейс не может быть оптимальным для всех. Обычно стоит различать интерфейс для пользователей и интерфейс для разработчиков. Дополнительно, часто в больших системах большинству пользователей предоставляется несколько упрошенный интерфейс, в то время как дополнительные возможности предоставляются пользователям-экспертам.
Экспертный интерфейс («полный интерфейс») обычно директивами ))юле!и«(е включает намного больше средств, чем хотел бы знать обычный пользователь системы. На практике, обычный пользовательский интерфейс получается после удаления из экспертного интерфейса как раз таких средств (и соответственно директив )) гле!аае), которые неизвестны рядовому пользователю. Термин «рядовой пользова- Глава 9. Исходные файлы и программы 27Я тель» не является уничижительным.
В тех областях, где я не обязан быть экспертом, я предпочитаю быть рядовым пользователем — это помогает избегать ненужных трудностей. В.З.З. Защита от повторных включений Целью применения множественных заголовочных файлов является построение согласованных и самодостаточных модулей. С точки зрения программы многие объявления, необходимые для обеспечения самодостаточности отдельных модулей, в целом избыточны. В больших программах такая избыточность может приводить к ошибкам, ибо определения классов или встраиваемых функций могут через директивы й«ис«иАе (в том числе и вложенные) попасть в отдельные единицы трансляции более одного раза (59.2.3). У нас есть две возможности: 1. Реорганизовать программу для устранения избыточности, или 2.
Найти способ безопасного повторного включения заголовков. Первый подход — именно он ведет к нашей последней версии калькулятора— весьма угомителен и непрактичен в случае реально больших программ. Кроме того, избыточность ведь делает отдельные части программ более осмысленными. Конечно, выигрыш от тщательного анализа избыточности и результирующего упрощения программы может быть значительным как с логической точки зрения, так и в плане сокращения времени компиляции.
Однако такой анализ редко когда бывает полным, так что в любом случае требуется найти метод преодоления негативных последствий множественного включения заголовков. Желательно, чтобы этот метод можно было применять систематически, ибо заранее неизвестна полнота анализа, проводимого пользователем. Традиционным решением проблемы является использование следующей комбинации директив условной компиляции — №(«йаеу; №г«е7«ие и «ела ~У файл еггог.«с «Циае7' САЕС ЕКОК Н №ае7«ие САЕС ЕКОК Н иагиелрасе Еггог ( ~7... Хг САЕС ЕЕЕОЕ Н «еий~ Содержимое заголовочного файла между №(1)и«еу'и №еий7игнорируется компилятором, если макроконстанта САЕС ЕККОК Н определена.
Таким образом, когда заголовочный файл егтог. 1« первый раз встречается при компиляции, его содержимое вычитывается полностью, а константа САКС ЕККОК Нстановится определенной (в результате действия директивы №Ае7«ие). Но если компилятор в пределах той же самой единицы трансляции встретит еггог. й еще раз, его содержимое будет проигнорировано. Этот метод, хоть он и опирается на трюкачество с макросами, реально работает и широко распространен в мире программирования на С и С++. Все стандартные заголовочные файлы используют этот метод. 27$ 9.4.
Программы Так как заголовочные файлы включаются в произвольном контексте, то следует учитывать возможность конфликта имен, из-за чего для макроконстант, контролирующих множественные включения, рекомендуется выбирать длинные и «безобразно» выглядящие имена. Как только люди привыкают к заголовочным файлам и получают метод избавления от множественных включений, они тотчас же приступают к неумеренному наращиванию количества прямо или косвенно включаемых заголовочных файлов.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
