С++ - довольно мощный язык. Это первый язык в нашей практике, позволивший конструировать обобщенные программные компоненты, обладающий математической точностью, изяществом и абстрактностью. При этом получающиеся компоненты не уступают в эффективности необобщенному коду .

Еще только предстоит раскрыть всю моп1ь сочетания пщблонов, абстрактных классов, обработки исключений и т.д. Я не думаю, что десятикратная разница в размере реализации ко.мпонент Буча [Booch, 1993b] на С++ и на Ada - это нехарактерный пример (см. раздел 8.4.1).

15.11.3. Влияние на другие компоненты С++

Аргумент шаблона может иметь встроенный или определенный пользователем тип. Это заставляло постоянно ду.мать о то.м, чтобы встроенные и пользовательские типы выглядели и вели себя по возможности одинаково. К сожалению, добиться полного тождества между ними нельзя. Причина - оставаясь в рамках coBMCCTHMOCTii с С, невозможно исключить нерегулярность встроенных типов. Но в некоторых отношениях встроенные типы все же выиграли от результатов работы над шаблонами.

Когда я только еще думал о шаблонах и позже, когда начал их применять, то обнаружил несколько случаев, в которых встроенные типы трактовались несколько иначе, чем классы. Это стало препятствием к написанию шаблонов, которые можно было бы использовать с аргументами как встроенных, так и пользовательских типов. Поэтому была поставлена цель обеспечить одинаковое поведение всех типов в семантическом и синтаксическом отношениях. Эта работа не окончена и по сей день.

Рассмотрим пример:

vector v(10); вектор из 10 элементов

Раньше такой синтаксис инициализации был неприменим к встроенным типам. Чтобы разрешить его, для встроенных типов введены понятия конструктора и деструктора, например:

int а(1); до версии 2.1 ошибка, теперь инициализирует а единицей

Я подумывал о том, чтобы пойти дальше и разрешить наследование от встроенных типов и явное объявление для них встроенных операторов. Но сдержался.

Если разрешить наследование от int, программист на С++ фактически не получит ничего принципиально нового по сравнению с члено.м типа int. Ведь в классе int нет виртуальных функций, которые производный класс .мог бы заместить. С другой стороны, правила преобразования в С настолько хаотичны, что никак не удается представить, будто int, short и т.д. - обычные классы с предсказуемым поведением. Они либо сохраняют совместимость с С, либо подчиняются четким правилам С++ для классов, но не то и другое одновременно.

Разрешить переопределять встроенные операторы - operator* {int, int), например, - значило заодно сделать язык подверженным мутациям. Однако идея разрешить синтез таких функций, чтобы можно было передавать указатели на них или ссылаться как-то иначе, довольно привлекательна.

Концептуально встроенные типы имеют конструкторы и деструкторы. Например:

template<class Т> class X {

Т а;

int i;

complex с; public:

ХО : а(Т()), i(intO), c(complexO) { } ...

Конструктор X инициализирует каждый член, вызывая для него конструктор по умолчанию. Умалчиваемый конструктор любого типа Т по определению дает то же значение, какое имела бы глобальная переменная типа Т, не инициализированная явно. Это уточнение ARM, где считалось, что X () возвращает неопределенное значение, если только для X не был определен конструктор по умолчанию.

Глава 16. Обработка исключений

Не паникуй!

Руководство для п/гешестаующих по Галактике автостопом

16.1. Введение

в первоначальном проекте С++ исключения рассматривались, но были отложены из-за нехватки времени на внимательное изучение вопросов проектирования и реализации, а также из опасения, что они могут сильно усложнить компилятор (см. раздел 3.15). Было понятно, что плохой проект может вызвать большие издержки во время выполнения и намного увеличить время, необходимое для переноса на другую платформу. Исключения считались важными для обработки ошибок в профаммах, составленных из независимо спроектированных библиотек.

Проектирование механизма исключений для С++ растянулось на несколько лет (с 1984 по 1989 гг.). Это была первая часть С++, которая проектировалась на глазах заинтересованной публики. Помимо бесчисленных обсуждений, через которые проходило любое включенное в С++ средство, несколько вариантов были изложены в статьях и подверглись широкому обсуждению. На последних этапах активное участие в работе принимал Эндрю Кениг, вместе которым мы написали статьи [Koenig, 1989а] и [Koenig, 1990]. Существенные фрагменты окончательной схемы были разработаны по пути на конференцию USENIX по С++, которая состоялась в ноябре 1987 г. в Санта-Фе. Промежуточные варианты проекта излагались также на встречах в компаниях Apple, DEC (Спринг Брук), Microsoft, IBM (Альмадена), Sun и в других местах. Я нашел людей, имевших реальный опыт работы с системами, поддерживающими обработку исключений. Первое серьезное обсуждение обработки исключений в С++ состоялось в Оксфорде летом 1983 г. Основные темы беседы с Тони Вильямсом (Топу Williams) из Лаборатории Резерфорда - проектирование отказоустойчивых систем и ценность статического контроля типов в механизме обработки исключений.

К моменту начала дебатов по поводу обработки исключений в комитете ANSI С++ опыт их использования в языке офаничивался библиотечными реализациями, предпринятыми компанией Apple, Майком Миллером [Miller,1988] и некоторыми другими. Единственную реализацию на уровне компилятора выполнил Майк Тиман [Tiemann, 1990]. Это вызывало беспокойство, хотя в общем все были согласны, что в какой-то форме обработка исключений очень пригодилась бы в С++. В частности, Дмитрий Ленков, основываясь на опыте компании Hewlett-Packard, выразил горячее желание иметь такой механизм. Только Дуг Макилрой считал, что наличие обработки исключений понизит надежность систем, поскольку