Б. Страуструп - Дизайн и Эволюция C++. 2006 (1160775), страница 98
Текст из файла (страница 98)
Это может привести к серьезным срывам э сроках поставки программы, составленной [пусть даже частично) из нескольких независимо разработанных библиотек. В таких библиотеках де-факто должен был бы согласовываться набор используемых исключений. Например, если подсистема Х обработыэает исключения, эоэбузщаемые я подсисте- ме У, а поставщик У вводит новый тип исключения, то код Х пришлось бы модифицироэоть. Пользователь и Х, и У не сможет поставить новую версию своего продукта, пока обе подсистемы не будут модифицированы.
В случаях когда используется много подсистем„это может прияесги к целой цепочке задержек. Надеже и там, где пользоэатель прибегает к услугам только одного поставщика, зто может стать причиной каскадной модификации кода и многократных перекомпиляций. Из-за такого рода проблем многие стараются вовсе не прибегать к механизму спецификации исключений или как-то обойти его» [Коеп(В, 1990]. Поэтому мы решили поддержать только проверку во время исполнения, а статический контроль оставить специальным инструментальным средствам.
«Аналогичная трудность возникает также при использовании динамической про»эрки. Однако э этом случае ее можно решить с помощью механизма группировки исключений, описанного э разделе 16.4. При наивном подходе новое исключение, добаэпенное к подсистеме У, осталось бы неперехяаченным или было бы преобразояано э эызоэ функции ппехрео с ег) ( ) некоторым явно эызыяаемым интерфейсом. Однако если подсистема У построена правильно, то эсе ее исключения были бы произэодными от класса уехоерс [оп.
Например: о1авв пенуехсерь[оп: роЬ1)о уехоарстоп ( /* ... */ ); При этом функция, объяэленная как уоьд Г() СЬгои (Хехоерггоп, уехоерс[оп, 10ехсерп[оп); смогла бы обработать исключение пеиуехоар сгоп, передаэ его функции, вызвавшей г ( )». НИВИИИИШ Статическая проверка Более подробное обсуждение см. в ]2пд, $9]. В 1995 г. была найдена схема, которая позволяет в какой-то мере выполнить статический контроль спецификации исключений, не порождая описанных выше проблем. Поэтому теперь спецификации исключений проверяются, так что инициализация и присваивание указателю на функцию, а также замещение виртуальных функций не могут нарушить защиту. Некоторые неожиданные исключения все же возможны, и они, как и раньше, перехватываются во время исполнения.
16.9.1. Вопросы реализации Как обычно, эффективности уделялось самое пристальное внимание. Очевидно, что можно было спроектировать такой механизм обработки исключений, реализовать который удалось бы лишь за счет явных затрат при вызове функций или неявных, связанных с невозможностью некоторых видов оптимизации. Похоже, нам удалось этого избежать, поскольку, по крайней мере, теоретически механизм исключений в С++ можно реализовать без каких бы то ни было временных издержек в программах, которые не возбуждают исключений.
Компилятор можно построить так, что все временные издержки будут проявляться лишь тогда, когда исключение действительно возбуждается ]Коеп18, 1990]. Ограничить расход памяти также ие составляет особой сложности, но очень трудно одновременно избежать и временных, и пространственных затрат. Сейчас есть уже несколько компиляторов, поддерживающих исключения, поэтому последствия компромиссов можно сравнить (см., например, 1Сашегоп, 1992]).
Как ни странно, обработка исключений почти не отражается на модели размещения объекта в памяти. Для обеспечения взаимодействия между точкой возбуждения исключения и обработчиком необходимо уметь представлять тип во время выполнения. Однако это можно сделать с помощью специализированного механизма, не затрагивающего объект в целом, используя структуры данных, поддерживающие идентификацию типа во время исполнения (см. раздел 14.2.6). Гораздо важнее то, что особенно значимым становится отслеживание точного времени жизни всех автоматических объектов. Прямолинейная реализация может привести к неоправданному увеличению кода, несмотря даже на то, что число дополнительных команд, которые действительно выполняются, невелико.
Техника реализации, представляющаяся оптимальной, заимствована из работ по языкам С!ц и Мгк]н1а-2+ ]Кочпег, 1986]. Основная идея состоит в том, чтобы составить таблицу диапазонов адресов кода, соответствующих состоянию вычислений, относящихся к обработке исключений. Для каждого диапазона регистрируются деструкторы и обработчики исключений, которые следует вызвать. Когда возбуждается исключение, механизм его обработки сравнивает текущее значение счетчика команд с адресами в таблице диапазонов.
Если оно попадает в один из диапазонов, то предпринимаются соответствующие действия; в противном случае производится раскрутка стека и в таблице ищется значение счетчика команд для вызвавшей функции. й[Пя' ИИИВИ!1 Обработка исключений 16.10.
Инварианты Поскольку язык С++ еще сравнительно молод, продолжает развиваться и в то же время широко используется, постоянно появляются предложения об улучшениях и расширениях. Как только в каком-нибудь языке появлялось новомодное средство, его рано или поздно начинали предлагать включить в С++. Бертран Мейер [Вегтгап([ Меуег) популяризировал старую идею о пред- и постусловиях и ввел для нее прямую поддержку в языке Е(ве! [Меуег, 1988). Естественно, то же самое предлагалось сделать и для С++. Определенная часть пользователей С всегда интенсивно работала с макросом а я яегс ( ), но не было приемлемого способа сообщить о нарушении утверждения во время выполнения.
Такой способ дают исключения, в то время как шаблоны позволяют отказаться от макросов. Например, вот как можно написать шаблон Аввегг ( ), который имитирует С-макрос аввегг (): севр1аге<с1авв Т, с1авв х> ьп11пе чей Аввегг(т ехрг,х х) 11 [)НПЕВ00) 1г (!ехрг) янгон х; ) Он будет возбуждать исключение х, если выражение ехрг ложно и мы не отключили проверку, задав ненулевое значение переменной ы()нв()о. Например: с1аяв Вад г агд ( ); чога г(вгг1пда я, гпг 1) ( Аявегг(0<=я аа 1<в.вгяе(), Вас г агд()); // ) чоЫ вгг1пд: ( Авяегг(р аа аа аа ) спеск() 0<=яв вя<тОО ЬАВак р(вв-1!==0 , 1пчаггапг); Простота, с которой в уже существующем языке С++ можно определять и проверять утверждения и инварианты, намного уменьшила число тех, кто непременно желает включить расширение для прямой поддержки верификации программ. Поэтому большая часть работы, относящейся к подобным приемам, проходила по разряду предложений по методике стандартизации [Оацтгоп,1992), или была связана с более серьезными системами верификации [1еа, 1990), или просто велась в рамках имеющегося языка.
Это наименее структурированный вариант такой техники. Я предпочитаю определять инварианты для классов в виде функций-членов, а не использовать утверждения напрямую. Например: Глава 17. Престранства имен Всегда рассматривайте то, что вм провктирувтв, в болев широком контексте. Злнвнь Саарннвн 17.1. Введение В С имеется единое глобальное пространство для всех имен, что не совсем удачно сочетается с одной функцией, структурой нлн единицей трансляции. Это порождает конфликты имен. Попытка решить проблему в первоначальном проекте С++ сводилась вот к чему: по умолчанию все имена объявлялись локальными для единицы трансляции, а чтобы они прочитывались в других единицах, следовало явно воспользоваться словом ехсегп.
Как отмечалось в разделе 3.12, с одной стороны, этого было мало для решения исходной задачи, с другой стороны, такое решение было недостаточно совместимым. Итак, идея провалилась. Занимаясь механизмом типобезопасного связывания (см. раздел 11.3), я снова вернулся к этой проблеме. Было замечено, что небольшое изменение синтаксиса, семантики и способа реализации конструкции ехсегп "С' ( /* ...
*/ позволило бы нам считать, что ехсегп ХХХ ( /* ... */ ) означает следующее: имена, объявленные внутри ХХХ, принадлежат отдельной области действия ХХХ и доступны в других областях действия лишь при наличии квалификатора ХХХ::. Следовательно, метод был в точности таким же, как при доступе к статическим членам класса извне этого класса. По разным причинам и прежде всего из-за нехватки времени описанная идея долгое время пролежала в столе и была извлечена на свет во время обсуждений на заседаниях комитета Ай)31/130 в начале 1991 г.
Сначала Кит Роуи (Ке!(Ь Коше) из М)сгозо(г предложил использовать нотацию Ьипд)е ХХХ ( /* ... */ )1 для определения именованной области действия и оператор цзе для импорта имен из области )эцпг)1 е в другую область действия. В дискусси на зту тему приняли участие несколько членов рабочей группы по расширениям, в том числе Стив Дович (Згече 0оч)с))), Дзг Брюк, Мартин О'Риордан и я. В конечном итоге Фолькер Баух (1/о)кег ВацсЬе), Роланд Хартингер (Ко!апг) Наг()пяег) и Эрвин Пространства имен Упру, представляющие компанию 3(ешепв, выдвинули предложение, в котором новых ключевых слов не было: ххх ( /* ...
*/ Это стало поводом для серьезных споров в группе по расширениям. В частности, Мартин О'Риордан показал, что нотация:: приводит к неоднозначному толкованию использования:: для членов классов и глобальных имен. К началу 1993 г. мне удалось сформулировать логически непротиворечивое предложение. Огромный вклад в техническое обсуждение вопроса о пространствах имен внесли Дзг Брюк, Джон Бранс, Стив Дович, Билл Гиббонс, Филипп Готрон, Тони Хансен, Питер Джуль, Эндрю Кениг, Эрик Крон (Ег(с КгоЬп), Дуг Макилрой, Ричард Миннер (ИсЬагд Мшпег), Мартин О'Риордан, Джон Скзллер ()оЬп ЯсаПег), Джерри Шварц, Марк Террибиль (Магй ТегпЬ(!е) и Майк Вило.
Кроме того, Вило ратовал за немедленное воплощение этих идей в конкретное предложение, чтобы иметь нужные средства для решения неминуемой проблемы имен в стандартной библиотеке 13О С++. Включение пространств имен в С++ одобрено на заседании комитета в Мюнхене в июле 1993 г. На заседании в СанХосе (ноябрь 1993 г.) решено использовать пространства имен для контроля за именами в стандартных библиотеках С и С++. 17.2.
Для чего нужны пространства имен При наличии только одного глобального пространства имен оказывается трудно писать фрагменты программ, которые будут связываться вместе, и при этом не опасаться возникновения конфликта имен. Например: // пу.Ы скат ((с)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}
