Бьерн Страуструп. Язык программирования С++. Специальное издание (2011) (1004033), страница 56
Текст из файла (страница 56)
Ь" Иисгийе <(овй еат> Иле!пав <ссгуре> Ключевое слово е)ггегп используется для объявления переменных, чтобы гарантировать отсутствие множественных определений при включении файла Ис. Ь в разные .с файлы. Соответствующие определения располагаются в том или ином . с файле. За вычетом реального кода файл !ехег. с будет выглядеть следующим образом: 2б7 9.3. Применяем заголовочные файлы Т.ехег<: Тоаеп га<ие Т.ехег::сигг <ой< аоиЫе Телег<:питЬег га!ие< за<: < з<ппя 1.ехег <: з<г!пя майе; Т.ехег<:Тайен га<ие1.ехег<:де« ойеп() (l* ...
*/) Использование заголовочных файлов гарантирует, что каждое объявление из этих файлов будет помещено в .с файл, содержащий соответствующее определение. Например, при компиляции!ехег. с компилятор повстречает объявление ,У из <<с Ь па<пезрасе Т.ехег ( ~У... Тойеп га!ие де« ойеп ( ) ) Т.ехег::Тойеп га!ие1,ехег: <яе« ойеп() ( l* ... *< ) Это, в свою очередь, гарантирует, что компилятором будут выявлены все случаи рассогласования типов.
Например, если бы функция яе« о!<ел () в объявлении возвращала бы значение типа Тойеп га1ие, а в определении — значение типа <и<, то компиляция файла 1ехег. с завершилась бы с ошибкой несоответствия типов. Если отсутствует определение, ошибку обнаружит компоновщик, а если нет объявления — это обнаружит компилятор. Файл рагзег.с будет выглядеть следующим образом: l/ файл ратег.с: 4!пс!и«е "«с.
Ь" «оиЫеРагзег::рпт(Ьоо<яе<) (!* .. *1) йоиЫе Рагзег::<егт(Ьоо< вен (!* ... *l ) «оиЫеРагзег::ехрг(Ьоо!ее<) (l* . */) А вот содержимое файла (а)з)е.с; У файл <аЫе.с: Ипс!и<(е "«с. Ь" зЫ:: тор< зЫ:: з<г!па, «оиЫе> <аЫе; Таблица символов является просто глобальной переменной <аЫе стандартного библиотечного типа <пар.
В программах реальных (больших) размеров загрязнение глобального пространства имен вызовет в конце концов проблемы. Но здесь я допустил эту небрежность намеренно, чтобы появился повод предупредить о возможных проблемах. Наконец, файл <па)п.
с имеет следующий вид: !< файл тат.с: Ь!пс!и<<с "«с. Ь" 4Ыс!ийе <за<геев> Ь!пс!и<ге «озиеат> Ь«Рг!ге<<: по о/' еггогз = О; зМ:: и<сеет* Т)г!ге< <: !при<= 0< Глава 9. Исходные файлы и программы ааа1 Эггаег: схИр ( ) ( l * ... *l ) !т тагн Пнг агде, енаг' агег]] ) ] /* ... */) Функция та)и ( ), как стартовая функция программы, долхсна быть глобальной, и поэтому она не помещена ни в какое пространство имен.
Физическую структуру программы можно представить графически: гаЫе. с Заголовочные файлы в верхней части рисунка являются стандартными библиотечными заголовками. В большинстве случаев при анализе программ эти заголовочные файлы можно опустить, ибо про эту стабильную составляющую практически любой программы и так все известно заранее. Крошечные программы можно предельно упростить, поместив все директивы )) 1ис1иЫе в один заголовочный файл. Такой стиль физического сегментирования программ хорош для программ малых размеров, отдельные части которых не предполагается использовать отдельно.
Если используются пространства имен, то логическая структура программы также отражается в с)с.й. Если же пространства имен не используются, то структура становится туманной. В этом случае помогают комментарии. Для программ больших размеров стиль сегментирования с единственным заголовочным файлом становится неработоспособным в обычных средах разработки, ориентированных на файлы. Изменения в единственном заголовочном файле вызывают перекомпиляцию всей программы, а работа с этим единственным файлом разных программистов чревата ошибками. По мере роста размеров программ их логическая структура катастрофически ухудшается, если разработка ведется без опоры на пространства имен и классы.
9.3.2. Несколько заголовочных файлов Альтернативой является такая физическая организация программы, когда каждому логическому модулю соответствует свой заголовочный файл, содержащий все необходимые модулю объявления. Каждый . с файл располагает соответствующим заголовочным файлом, определяющим его интерфейс. Каждый . с файл директивами )) 1ие1и4е включает свой заголовочный файл и иные заголовочные файлы, определяющие то, что нужно модулю от других модулей. В этом случае физическая организация соответствует логической организации модуля.
Интерфейс для пользователей модуля размещается в . й файле, интерфейс для реализации модуля — в файле с суффиксом )тр1. 1г, а сама реализация модуля (функции, определения переменных и т.д.) сосредотачивается в . е файле. В результате модуль представляется тремя файлами. Например, интерфейс для пользователей модуля парсера располагается в файле рагхег. й: 269 9.3.
Применяем заголовочные файлы /файл рапег.Ь: пагпезрасе Рагзег ( аоиЫе ехрг (Ьоо1 де!); ) Заголовочный файл реализации этого модуля помещается в заголовочный файл рагзег ипр1. Ь: //файл рагзег )тр(.Ь: №!пс)ийе "рагзе«. Й" Ыпс!иИе "епог. Ь" Ипс1ийе "!ехег. Ь " // интерфейс длл реализаяии патезрасе Рагзег ( ИоиЫе рпт (Ьоо! яег); аоиЫе !епп (Ьоо1 де!); йоиЫе ехрг (Ьоо) лей ) из!пд Хехег::де! !ойеп; из!па Еехег:: сиге Зой/ ) Сюда включен и заголовочный файл для пользователей рагзег.
Ь, чтобы компилятор имел возможность проверить согласованность объявлений 59.3. ) ). Реализация парсера располагается в файле рагзег. с, включающем все необходимые ему заголовочные файлы: // файл рагзег.с: №)пс!ийе "рагзег №тр!. Ь" Нпс!ийе "!аЫе. Ь" йоиЫе Рагзет: рпт (Ьоо! ае!) ( / * ... */ ) аоиЫе Рагзег::зегт (Ьоо1де!) (/* ... */) йоиЫеРагзег::ехрг(Ьоо(де!) (/* ... */) В графическом виде парсер и его использование управляющим модулем выглядит так: Как и было задумано, здесь достигнуто близкое соответствие логической структуре, описанной ранее в 58.3.2. Для ее дальнейшего упрощения можно было бы по- 270 Глава 9.
Исходные файлы и программы местить директиву Ынс!иде "гаЫе.й" в файл рагзег 1тр1.1» вместо файла рагяег.с. Однако файл гаЫе. Ь не относится к общему интерфейсу функций синтаксического анализатора (парсера); скорее он нужен лишь реализации этих функций. Более точно, он нужен лишь функции ргия (), так что если уж мы на самом деле были бы настроены минимизировать зависимости, то стоило бы функцию ргин() вьщелить в отдельный . с файл и только в него включатыаЫе. 1с Столь тщательная проработка уместна, в первую очередь, для больших программ.
Для них типично включение дополнительных заголовочных файлов только там, где это требуется отдельным функциям. Более того, для больших программ нередко используется несколько заголовочных файлов с суффиксом 1тр1.й, поскольку разным подмножествам функций модуля требуются разные интерфейсы реализации. Обратите внимание на то, что применение суффикса йнр1. й не только не является стандартом, но даже и нельзя сказать, что сильно распространенным явлением; просто лично мне нравится такой стиль именования. Итак, для чего же все-таки стоит возиться с более сложной схемой со многими заголовочными файлами? Ведь намного проще поместить все объявления в единственный заголовочный файл Фс.
Й. Схема со многими заголовочными файлами отвечает масштабу модулей, во много раз больших нашего игрушечного парсера, и масштабу программ, намного больших нашего калькулятора. Фундаментальная идея сводится к большей локализа)(ии. Когда программист анализирует и модифицирует большую программу, ему важно иметь возможность сфокусироваться на относительно небольшом фрагменте кода. Схема организации программы со многими заголовочными файлами позволяет четко выявить, от чего зависит, например, модуль парсера, и игнорировать остальные части нрограммы. Подход же с единственным заголовочным файлом заставляет нас в рамках каждого модуля просматривать все объявления и решать, какие из них необходимы.
Факт состоит в том, что при этом приходится работать с кодом в условиях неполной информации, отталкиваясь от локальной перспективы. Подход же со многими заголовочными файлами позволяет нам в локальной перспективе успешно продвигаться «изнутри наружу» (Ггош г))е )пя)де ош). Метод с единственным заголовком, как и любая другая организация программ с глобальным хранением информации, требует подхода»сверху вниз» (гор-дошл арргоасй) и заставляет нас бесконечно выяснять, что от чего зависит. Более сильная локализация ведет, к тому же, и к меньшим временам компиляции.
Эффект может быть весьма значительным. Я наблюдал уменьшение времени 9.3. Применяем заголовочные файлы 271 компиляции в десятки раз из-за лучшего анализа зависимостей и лучшего примене- ния заголовочных файлов. 9.3.2.1. Остальные модули калькулятора Остальные модули калькулятора можно организовать аналогично модулю парсера, Однако они столь малы, что для них нет нужды в собственных ип№р.№г файлах.
Такие файлы нужны лишь логическим модулям, содержащим наборы функций с общим контекстом. Обработчик ошибок сократился до набора типов исключений, так что для него не требуется еггог.с файл: l/ файл еггог. №с нателрасе Еггог лггисг Хе«о а!«1ае) ); л!гис! Зупигх еггог ( сопл! сйа«* р; ЯупШк еггог )сопл! сна«* о) )р = о; ) )' ) Лексический анализатор обладает довольно большим и более запутанным интерфейсом: У файл 1ехег.№с №!пс1иае <л!г!пе> пателрасе Еехег ) епигп Топеп га)ие ( )УАМЕ, )УЮМВЕК, РШК= ' + ', МТ)к1Б= ' - ', РВТЮТ='; ', АЮЯЖ)У='=', )' ЕХТ>, МИ; — '*', ЕР=' (', 1)Л'= ' ! ' ВР=' ) ' ех!егн Тайен го№ие си«г гой; ехгегп йоиЫе питье« га1ие; ех!егн лЫ:: лгг№пл л!г!пе га!ие; Тайен гагиеае! !ойеп[) ) У файл )ехег.с: №1пс1иае "1ехег. й" №1нс1иае "ело«.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
