Б. Страуструп - Дизайн и Эволюция C++. 2006 (1160775), страница 61
Текст из файла (страница 61)
К сожалению, многие включили в свой код определения )(Оь~, ы1~, ып11, пп11 и т.д., так что вволить еше одно просто опасно. Есть одна ошибка, которую невозможно обнаружить, если О (как бы он пи был назван) используется в качестве нулевого указателя. Рассмотрим пример: чо1о Г(спас*); »оьс) 0() ( >(О); ) // вызывает т(с)>ат*) »огс) 1(с)>аг*)> »оьс) 1(1пп)> чо1й д() ( 1(0)> ) // вызывает т(1пк) Этот неприятный побочный эффект возникает из-за того, что Π— это значение типа йпс, которое может быть расширено до нулевого указателя, а не прямое обозначение последнего. Думаю, что хороший компилятор мог бы выдать предупреждение, но во время работы над С(гонг я об этом не подумал. Можно было Г>ы считать вызов б ( О ) неоднозначным, а не разрешать его в пользу б (1пс ), но это могло бы не понравиться тем, кто хочет видеть особый смысл в (0О( ) или п11.
Если добавить ешс одну функцию б ( ), то семантика д ( ) изменится бсз предупреждения: ИИИИИИИ! й Перегрузка После очередной перепалки в сошр.1апй.с++ и сошр.!апя.с один из моих друзей заметил: «Если проблема нулевого указателя для них самая страшная, то им просто повезло». Опыт показывает, что использование () для обозначения нулевого указателя на практике не вызывает сложностей. Но меня по-прежнсму удивляет правило, согласно которому результат вычисления любого константного выражения, равный О, принимается в качестве нулевого указателя. Согласно этому правилу, 2-2 и --1 — нулевые указатели.
Но ведь ясно, что присвоение 2+2 или -1 указателю — ошибка типизации. Безусловно, разработчикам компиляторов такое правило тоже не нравится. П.2.4. Ключевое слово о)/ег!оаэи В первоначальном варианте в С++ допускалось использование одного имени для обозначения двух функций только после объявления оуег1оад. Например: очег1оад шах; // "очег1оад" — устарело в 2.0 1лс пах[1лс,1лс); боиЫе шах(бооЬ1е,с(оиЫе) ) Я счел слишком опасным такое испояьзование без явного декларирования намерения.
Например: 1лс аЬв(ьлс) ) // "очег1оас( аЬв" отсутствует с)оиЫе аЬв (боиЫе) ) // раньше считалось ошибкой Тол(у было две причины: ш опасение необнаруженных неоднозначностей; ш потенциальная возможность того, что программа может быть некорректно скомпонована, если программист явно не объявит, какие функции следует перегружать. Первое соображение оказалось беспочвенным.
Те немногие проблемы, с которыми все же пришлось столкнуться, устранялись за счет применения независимых от порядка правил разрешения перегрузки. Второе опасение действительно связано с общей сложностью, возникающей из-за правил раздельной компиляции в С, но к перегрузке это отношения не имеет 1см. раздел 11.3). С другой стороны, сами объявления оуег1оас( стали источником серьезной проблемы: нельзя объединить два независимо разработанных фрагмента программы, в которых одно и то же имя используется для разных функций, если в обоих случаях оно не объявлено как перегруженное. Но так обычно не происходит; чаше всего нужно перегрузить имя библиотечной функции С, объявленное в заголовочном файле, например: /* заголовочный файл стандартной математической библиотеки шасЬ.Ь */ боиЫе вцгс(боиЫе); /* */ // Заголовочный файл библиотеки для работн с комплексными числами // сошр1ех.Ь очег1оад впгг; сошр1ех впгс(сошр1ех); // Типобезопаснав компоновка ЛИИИИИИБ Теперь можно написать )))пс1п<)е <сощр1ех.'и> )))пс1пс1е <щасш Ь> но не ))1пс1и<)е <наСЫД> ))1пс1ное <сощр1ех.'и> поскольку использование слова очек1оас) только во втором объявлении — ошибка.
Эту проблему удастся смягчить, изменив порядок объявлений, введя ограничения на использование заголовочных файлов или вставки оуег1оа<) повсюду. Но все-таки гораздо лучшим решением представлялся отказ от объявлений оуег1оас) и самого ключевого слова. 11.3. Типобезопасная компоновка Компоновка в С проста и абсолютно небезопасна. Вы объявляете функцию ехоетп тоад Г)сваг); и компоновщик связывает эту й со всем, что найдет.
А обнаружить он может функцию с совершенно другим числом аргументов или даже вовсе не функцию. Обычно это приводит к ошибке во время выполнения (нарушению защиты и т.д.). Особенно неприятными проблемы компоновки становятся при увеличении программы и интенсивном использовании библиотек.
Программисты на С научились с этим справляться. Однако с появлением механизма перегрузки задачу надо было срочно решать, но так, чтобы оставалась возможность вызывать написанные на С функции без дополнительных сложностей и лишних затрат. 113.1. Перегрузка и компоновка До версии 2.0 проблема компоновки программ, написанных на смеси С и С++, решалась так: имя, сгенерированное для С++-функции, должно по возможности быть таким же, как было бы сгенерировано для одноименной С-функции. Поэтому функция ореп () получила бы имя ореп в системе, где С не модифицирует имена, и ореп — в системе, где в начало добавляется подчеркивание, и т.д. Для перегруженных функций такой простой схемы недостаточно.
Частично ключевое слово оуег1 о ад и было введено для того, чтобы отличить трудный случай от легкого (см. также раздел 3.6). В основе первоначального решения, как и последующих, лежала идея о том, чтобы закодировать информацию о типе в имени, с которым работает компоновщик (см. раздел 3.3.3). Чтобы оставить возможность компоновки с С-функцией, кодировались имена только второго и последующих вариантов перегруженной функции. Стало быть, программисту приходилось писать: оуег1оаг) вчтс; с)опЫе ветс)с)оиЫе); // компоновщику доступно: ветс сощр1ех вс)тс)сотр1ех); // компоновщику доступно: вцтС Ртсощр1ех ПИИИИИИ6' Перегрузка ы отсутствие у компоновщика возможности контролировать типы; л использование ключевого слова отгег1оас); д связывание фрагментов программы, написанных на С и С++.
Первая проблема решается путем добавления к имени каждой функции информации о се типе. Вторая — отказом от слова очег1оаса Для решения третьей программисту на Се+ пеобхолнмо явно указать, когда функция должна связываться в ст.иле С. Поэтому в 18(гоцз(гцр, 1988а) я писал: «Вопрос в том, можно пи реализовать решение, основанное на этих трех посылках, без заметных затрат и с минимальными неудобствами для программистов на С++. Идеальное решение должно: ш не требоват~ никаких изменений в С++; а обеспечит~ типобезопасную компоновку; ы допускать простое и удобное связывание с С-функциями; я не <ломатья существующий код на С+т-; а разрешат~ использование заголовочных файлов С (в стиле АЬ(5))) ".~ обеспечивать хорошее обнаружение и диагностику ошибок; ш быть удобным инструментом для построения библиотек; О не приводить к издержкам во время выполнения, компиляции и компоновки. Р(ам не удалось найти решение, которое бы строго удовлетворяло всем этим условиям, но принятая схема является неплохим вариантомж Ясно, что во время компоновки потребовалось бы проверять все типы.
Но тогда возникал вопрос, как это сделать без написания нового компоновщика для каждой системы. 11.3.2. Реализация компоновки в С++ Имя каждой С++-фупкцин кодируется путем добавления к нему типов аргументов, Этим гарантируется, что программа будет скомпонована только в том случае, если у каждой функции есть определение и типы аргументов в объявлении и определении совпадают. Рассмотрим, например, объявления ( г* */ ) // определяет 1 Р1 1(1пг 1, с)гад* 1) ( /* ... */ ) // определяет 1 Рэвс которые можно правильно обработать; ехгегп 1(1пс); // относится к 1 Р1 ехсегп 1()пг,спвг*); // относится к 1 Р1Рс ехсегп 1(г(оцЬ1е,г(оцЫе)г // относится к 1 Рад Компилятор Се+ генерировал код. Оп ссылался на эс(гг и эс(гг Р7солгр1ех. К счастью, это Г>ьшо задокумснтировано только в разделе «Ошибки» руководства по С+е.
Использовавшаяся до 2.0 схема перегрузки взаимодействовала с традиционной схемой компоновки С-програмл( таким способом, при котором становились очевилными худшие стороны того и другого. Нам пришлось решать три проблемы: ! ФИИИИИИН Типобезопасная компоновка «ота д() ( Г (1); // связывается с Г Г Е(1,"аздб"); // связывается с Е у1рс Е(1,1); // попытка связать с 1 «бд // оиибка во время компоновки: // 1 «бб ые определена Это оставляет открытым вопрос о том, как вызвать С- или С++-функции. Для этого программист должен указать, что функция имеет С-компоновку.
В противном случае предполагается, что это С++-функция, и ее имя кодируется. С этой целью в Сев была введена спецификация компоновки: ехеетп "С" ( бапь1е в«)гк(доы)зте)« // волк(бов)зте) имеет С-компоновку ) Л.З.З. Днализ пройденного пути Видимо, мы правильно определили приоритеты: типобезопасная компоновка, наличие разумной реализации и возможность явной компоновки с программами, написанными на других языках.
Как и ожидалось, с помощью новой системы компоновки решался целый ряд проблем. Помимо всего прочего, в процессе перехода к новому стилю обнаружилось на удивление большое число ошибок при компоновке старых программ, написанных на С и С++. Я тогда отметил: «При переходе на типобезопасную компоновку чувствуешь себя, как после первой проверки С- программы с помощью 11пс, — несколько обескураженно». ьйпс — это популярный инструмент проверки раздельно компилируемых частей С-программы на предмет непротиворечивого использования типов [Кегп(яЬап, 1984).
Во время опытной эксплуатапии типобезопасной компоновки я пытался отслеживать результаты ее Спецификация компоновки не затрагивает семантику программы, в которой используется зс(гс ( ), а лишь дает компилятору информацию, что при генерировании объектного кода он должен использовать для вцгс ( ) принятые в С соглашения об именах. Это означает, что имя данного экземпляра зс(к с () будет равно вс(гс или зцгс, или иному варианту, в зависимости от конкретной системы.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
