Chapter 1. Применение наследования в C++

При использовании наследования указатель или ссылка на тип базового класса способен адресовать объект любого производного от него класса. Возможность манипулировать такими указателями или ссылками независимо от фактического типа адресуемого объекта называется полиморфизмом. В этой главе мы рассмотрим три функции языка, обеспечивающие специальную поддержку полиморфизма. Сначала мы познакомимся с идентификацией типов во время выполнения (RTTI – Run-time Type Identification), которая позволяет программе узнать истинный производный тип объекта, адресованного ссылкой или указателем на тип базового класса. Затем расскажем о влиянии наследования на обработку исключений: покажем, как можно определять их в виде иерархии классов и как обработчики для типа базового класса могут перехватывать исключения производных типов. В конце главы мы вернемся к правилам разрешения перегрузки функций и посмотрим, как наследование влияет на то, какие преобразования типов можно применять к аргументам функции, и на выбор наилучшей из устоявших.

Content

§ 1.1. Идентификация типов во время выполнения

§ 1.2. Исключения и наследование

§ 1.3. Разрешение перегрузки и наследование

§ 1.1. Идентификация типов во время выполнения

RTTI позволяет программам, которые манипулируют объектами через указатели или ссылки на базовые классы, получить истинный производный тип адресуемого объекта. Для поддержки RTTI в языке C++ есть два оператора:

оператор dynamic_cast поддерживает преобразования типов во время выполнения, обеспечивая безопасную навигацию по иерархии классов. Он позволяет трансформировать указатель на базовый класс в указатель на производный от него, а также преобразовать l-значение, ссылающееся на базовый класс, в ссылку на производный, но только в том случае, если это завершится успешно;
оператор typeid позволяет получить фактический производный тип объекта, адресованного указателем или ссылкой.

Однако для получения информации о типе производного класса операнд любого из операторов dynamic_cast или typeid должен иметь тип класса, в котором есть хотя бы одна виртуальная функция. Таким образом, операторы RTTI – это события времени выполнения для классов с виртуальными функциями и события времени компиляции для всех остальных типов. В данном разделе мы более подробно познакомимся с их возможностями. Использование RTTI оказывается необходимым при реализации таких приложений, как отладчики или объектные базы данных, когда тип объектов, которыми манипулирует программа, становится известен только во время выполнения путем исследования RTTI-информации, хранящейся вместе с типами объектов. Однако лучше пользоваться статической системой типов C++, поскольку она безопаснее и эффективнее.

19.1.1. Оператор dynamic_cast

Оператор dynamic_cast можно применять для преобразования указателя, ссылающегося на объект типа класса в указатель на тип класса из той же иерархии. Его также используют для трансформации l-значения объекта типа класса в ссылку на тип класса из той же иерархии. Приведение типов с помощью оператора dynamic_cast, в отличие от других имеющихся в C++ способов, осуществляется во время выполнения программы. Если указатель или l-значение не могут быть преобразованы в целевой тип, то dynamic_cast завершается неудачно. В случае приведения типа указателя признаком неудачи служит возврат нулевого значения. Если же l-значение нельзя трансформировать в ссылочный тип, возбуждается исключение. Ниже мы приведем примеры неудачного выполнения этого оператора.

Прежде чем перейти к более детальному рассмотрению dynamic_cast, посмотрим, зачем его нужно применять. Предположим, что в программе используется библиотека классов для представления различных категорий служащих компании. Входящие в иерархию классы поддерживают функции-члены для вычисления зарплаты:

class employee {
public:
   virtual int salary();
};

class manager : public employee {
public:
   int salary() override;
};

class programmer : public employee {
public:
   int salary() override;
};

void company::payroll(employee *pe) {
   // используется pe->salary()
}

В компании есть разные категории служащих. Параметром функции-члена payroll() класса company является указатель на объект employee, который может адресовать один из типов manager или programmer. Поскольку payroll() обращается к виртуальной функции-члену salary(), то вызывается подходящая замещающая функция, определенная в классе manager или programmer, в зависимости от того, какой объект адресован указателем.

Допустим, класс employee перестал удовлетворять нашим потребностям, и мы хотим его модифицировать, добавив еще одну функцию-член bonus(), используемую совместно с salary() при расчете платежной ведомости. Для этого нужно включить новую функцию-член в классы, составляющие иерархию employee:

class employee {
public:
   virtual int salary();       // ca?ieaoa
   virtual int bonus();        // i?aiey
};

class manager : public employee {
public:
   int salary() override;
};

class programmer : public employee {
public:
   int salary() override;
   int bonus() override;
};

void company::payroll(employee *pe) {
   // используется pe->salary() и pe->bonus()
}

Если параметр pe функции payroll() указывает на объект типа manager, то вызывается виртуальная функция-член bonus() из базового класса employee, поскольку в классе manager она не замещена. Если же pe указывает на объект типа programmer, то вызывается виртуальная функция-член bonus() из класса programmer.

После добавления новых виртуальных функций в иерархию классов придется перекомпилировать все функции-члены. Добавить bonus() можно, если у нас есть доступ к исходным текстам функций-членов в классах employee, manager и programmer. Однако если иерархия была получена от независимого поставщика, то не исключено, что в нашем распоряжении имеются только заголовочные файлы, описывающие интерфейс библиотечных классов и объектные файлы с их реализацией, а исходные тексты функций-членов недоступны. В таком случае перекомпиляция всей иерархии невозможна.

Если мы хотим расширить функциональность библиотеки классов, не добавляя новые виртуальные функции-члены, можно воспользоваться оператором dynamic_cast.

Этот оператор применяется для получения указателя на производный класс, чтобы иметь возможность работать с теми его элементами, которые по-другому не доступны. Предположим, что мы расширяем библиотеку за счет добавления новой функции-члена bonus() в класс programmer. Ее объявление можно включить в определение programmer, находящееся в заголовочном файле, а саму функцию определить в одном из своих исходных файлов:

class employee {
public:
   virtual int salary();
};

class manager : public employee {
public:
   int salary();
};

class programmer : public employee {
public:
   int salary();
   int bonus();
};

Напомним, что payroll() принимает в качестве параметра указатель на базовый класс employee. Мы можем применить оператор dynamic_cast для получения указателя на производный programmer и воспользоваться им для вызова функции-члена bonus():

void company::payroll(employee *pe) {
   programmer *pm = dynamic_cast<programmer* >(pe);

   // anee pe oeacuaaao ia iauaeo oeia programmer,
   // oi dynamic_cast auiieieony oniaoii e pm aoaao
   // oeacuaaou ia ia?aei iauaeoa programmer
   if (pm) {
      // eniieuciaaou pm aey auciaa programmer::bonus()
   }
   // anee pe ia oeacuaaao ia iauaeo oeia programmer,
   // oi dynamic_cast auiieieony iaoaa?ii
   // e pm aoaao niaa??aou 0
   else {
      // eniieuciaaou ooieoee-?eaiu eeanna employee
   }
}

Оператор

dynamic_cast<programmer*>(pe)

приводит свой операнд pe к типу programmer*. Преобразование будет успешным, если pe ссылается на объект типа programmer, и неудачным в противном случае: тогда результатом dynamic_cast будет 0.

Таким образом, оператор dynamic_cast осуществляет сразу две операции. Он проверяет, выполнимо ли запрошенное приведение, и если это так, выполняет его. Проверка производится во время работы программы. dynamic_cast безопаснее, чем другие операции приведения типов в C++, поскольку проверяет возможность корректного преобразования.

Если в предыдущем примере pe действительно указывает на объект типа programmer, то операция dynamic_cast завершится успешно и pm будет инициализирован указателем на объект типа programmer. В противном случае pm получит значение 0. Проверив значение pm, функция company::payroll() может узнать, указывает ли pm на объект programmer. Если это так, то она вызывает функцию-член programmer::bonus() для вычисления премии программисту. Если же dynamic_cast завершается неудачно, то pe указывает на объект типа manager, а значит, необходимо применить более общий алгоритм расчета, не использующий новую функцию-член programmer::bonus().

Оператор dynamic_cast употребляется для безопасного приведения указателя на базовый класс к указателю на производный. Такую операцию часто называют понижающим приведением (downcasting). Она применяется, когда необходимо воспользоваться особенностями производного класса, отсутствующими в базовом. Манипулирование объектами производного класса с помощью указателей на базовый обычно происходит автоматически, с помощью виртуальных функций. Однако иногда использовать виртуальные функции невозможно. В таких ситуациях dynamic_cast предлагает альтернативное решение, хотя этот механизм в большей степени подвержен ошибкам, чем виртуализация, и должен применяться с осторожностью.

Одна из возможных ошибок – это работа с результатом dynamic_cast без предварительной проверки на 0: нулевой указатель нельзя использовать для адресации объекта класса. Например:

void company::payroll(employee *pe) {
   programmer *pm = dynamic_cast<programmer* >(pe);

   // iioaioeaeuiay ioeaea: pm eniieucoaony aac i?iaa?ee cia?aiey
   static int variablePay = 0;
   variablePay += pm->bonus();
   // ...
}

Результат, возвращенный dynamic_cast, всегда следует проверять, прежде чем использовать в качестве указателя. Более правильное определение функции company::payroll() могло бы выглядеть так:

void company::payroll(employee *pe) {
   // auiieieou dynamic_cast e i?iaa?eou ?acoeuoao
   if (programmer *pm = dynamic_cast<programmer* >(pe)) {
      // eniieuciaaou pm aey auciaa programmer::bonus()
   }
   else {
      // eniieuciaaou ooieoee-?eaiu eeanna employee
   }
}

Результат операции dynamic_cast используется для инициализации переменной pm внутри условного выражения в инструкции if. Это возможно, так как объявления в условиях возвращают значения. Ветвь, соответствующая истинности условия, выполняется, если pm не равно нулю: мы знаем, что операция dynamic_cast завершилась успешно и pe указывает на объект programmer. В противном случае результатом объявления будет 0 и выполняется ветвь else. Поскольку теперь оператор и проверка его результата находятся в одной инструкции программы, то невозможно случайно вставить какой-либо код между выполнением dynamic_cast и проверкой, так что pm будет использоваться только тогда, когда содержит правильный указатель.

В предыдущем примере операция dynamic_cast преобразует указатель на базовый класс в указатель на производный. Ее также можно применять для трансформации l-значения типа базового класса в ссылку на тип производного. Синтаксис такого использования dynamic_cast следующий:

dynamic_cast<Type&>(lval)

где Type& – это целевой тип преобразования, а lval – l-значение типа базового класса. Операнд lval успешно приводится к типу Type& только в том случае, когда lval действительно относится к объекту класса, для которого один из производных имеет тип Type.

Поскольку нулевых ссылок не бывает (см. раздел 3.6), то проверить успешность выполнения операции путем сравнения результата (т.е. возвращенной оператором dynamic_cast ссылки) с нулем невозможно. Если вместо указателей используются ссылки, условие

if (programmer *pm = dynamic_cast<programmer*>(pe))

нельзя переписать в виде

if (programmer &pm = dynamic_cast<programmer&>(pe))

Для извещения об ошибке в случае приведения к ссылочному типу оператор dynamic_cast возбуждает исключение. Следовательно, предыдущий пример можно записать так:

#include <typeinfo>
void company::payroll(employee &re) {
   try {
      programmer &rm = dynamic_cast<programmer&>(re);
      // eniieuciaaou rm aey auciaa programmer::bonus()
   }
   catch (std::bad_cast) {
      // eniieuciaaou ooieoee-?eaiu eeanna employee
   }
}

В случае неудачного завершения ссылочного варианта dynamic_cast возбуждается исключение типа bad_cast. Класс bad_cast определен в стандартной библиотеке; для ссылки на него необходимо включить в программу заголовочный файл <typeinfo>. (Исключения из стандартной библиотеки мы будем рассматривать в следующем разделе.)

Когда следует употреблять ссылочный вариант dynamic_cast вместо указательного? Это зависит только от желания программиста. При его использовании игнорировать ошибку приведения типа и работать с результатом без проверки (как в указательном варианте) невозможно; с другой стороны, применение исключений увеличивает накладные расходы во время выполнения программы (см. главу 11).

19.1.2. Оператор typeid

Второй оператор, входящий в состав RTTI, – это typeid, который позволяет выяснить фактический тип выражения. Если оно принадлежит типу класса и этот класс содержит хотя бы одну виртуальную функцию-член, то ответ может и не совпадать с типом самого выражения. Так, если выражение является ссылкой на базовый класс, то typeid сообщает тип производного класса объекта:

#include <typeinfo>

programmer pobj;
employee &re = pobj;

// n ooieoeae name() iu iiciaeiieiny a iia?acaaea, iinayuaiiii type_info
// iia aica?auaao C-no?ieo "programmer"
std::cout << typeid(re).name() << std::endl;

Операнд re оператора typeid имеет тип employee. Но так как re – это ссылка на тип класса с виртуальными функциями, то typeid говорит, что тип адресуемого объекта – programmer (а не employee, на который ссылается re). Программа, использующая такой оператор, должна включать заголовочный файл <typeinfo>, что мы и сделали в этом примере.

Где применяется typeid? В сложных системах разработки, например при построении отладчиков, а также при использовании устойчивых объектов, извлеченных из базы данных. В таких системах необходимо знать фактический тип объекта, которым программа манипулирует с помощью указателя или ссылки на базовый класс, например для получения списка его свойств во время сеанса работы с отладчиком или для правильного сохранения или извлечения объекта из базы данных. Оператор typeid допустимо использовать с выражениями и именами любых типов. Например, его операндами могут быть выражения встроенных типов и константы. Если операнд не принадлежит к типу класса, то typeid просто возвращает его тип:

int iobj;
std::cout << typeid(iobj).name() << std::endl;   // ia?aoaaony: int
std::cout << typeid(8.16).name() <<std::endl;   // печатается: double

Если операнд имеет тип класса, в котором нет виртуальных функций, то typeid возвращает тип операнда, а не связанного с ним объекта:

class Base {  /* нет виртуальных функций */ };
class Derived : public Base { /* iao ae?ooaeuiuo ooieoee */ };
Derived dobj;
Base *pb = &dobj;
std::cout <<typeid(*pb).name() << std::endl;  // печатается: Base

Операнд typeid имеет тип Base, т.е. тип выражения *pb. Поскольку в классе Base нет виртуальных функций, результатом typeid будет Base, хотя объект, на который указывает pb, имеет тип Derived.

Результаты, возвращенные оператором typeid, можно сравнивать. Например:

#include <typeinfo>

employee *pe = new manager;
employee& re = *pe;
if (typeid(pe) == typeid(employee*))  // enoeiii
   // ?oi-oi naaeaou
/*
if (typeid(pe) == typeid(manager*))  // ei?ii
if (typeid(pe) == typeid(employee))  // ei?ii
if (typeid(pe) == typeid(manager))   // ei?ii
*/

Условие в инструкции if сравнивает результаты применения typeid к операнду, являющемуся выражением, и к операнду, являющемуся именем типа. Обратите внимание, что сравнение

typeid(pe) == typeid(employee*)

возвращает истину. Это удивит пользователей, привыкших писать:

// вызов виртуальной функции
pe->salary();

что приводит к вызову виртуальной функции salary() из производного класса manager. Поведение typeid(pe) не подчиняется данному механизму. Это связано с тем, что pe – указатель, а для получения типа производного класса операндом typeid должен быть тип класса с виртуальными функциями. Выражение typeid(pe) возвращает тип pe, т.е. указатель на employee. Это значение совпадает со значением typeid(employee*), тогда как все остальные сравнения дают ложь.

Только при употреблении выражения *pe в качестве операнда typeid результат будет содержать тип объекта, на который указывает pe:

typeid(*pe) == typeid(manager)    // истинно
typeid(*pe) == typeid(employee)   // ложно

В этих сравнениях *pe – выражение типа класса, который имеет виртуальные функции, поэтому результатом применения typeid будет тип адресуемого операндом объекта manager.

Такой оператор можно использовать и со ссылками:

typeid(re) == typeid(manager)     // истинно
typeid(re) == typeid(employee)    // ложно
typeid(&re) == typeid(employee*)  // истинно
typeid(&re) == typeid(manager*)   // ложно

В первых двух сравнениях операнд re имеет тип класса с виртуальными функциями, поэтому результат применения typeid содержит тип объекта, на который ссылается re. В последних двух сравнениях операнд &re имеет тип указателя, следовательно, результатом будет тип самого операнда, т.е. employee*.

На самом деле оператор typeid возвращает объект класса типа type_info, который определен в заголовочном файле <typeinfo>. Интерфейс этого класса показывает, что можно делать с результатом, возвращенным typeid.

19.1.3. Класс type_info

Точное определение класса type_info зависит от реализации, но некоторые его характерные черты остаются неизменными в любой программе на C++:

class type_info {
   // представление зависит от реализации
private:
   type_info(const type_info&);
   type_info& operator= (const type_info&);
public:
   virtual ~type_info();

   int operator==(const type_info&);
   int operator!=(const type_info&);

   const char * name() const;
};

Поскольку копирующие конструктор и оператор присваивания – закрытые члены класса type_info, то пользователь не может создать его объекты в своей программе:

#include <typeinfo>

type_info t1;  // ошибка: нет конструктора по умолчанию
               // ошибка: копирующий конструктор закрыт
type_info t2 (typeid(unsigned int));

Единственный способ создать объект класса type_info – воспользоваться оператором typeid.

В классе определены также операторы сравнения. Они позволяют сравнивать два объекта type_info, а следовательно, и результаты, возвращенные двумя операторами typeid.

typeid(re)  == typeid(manager)     // истинно
typeid(*pe) != typeid(employee)    // ложно

Функция name() возвращает C-строку с именем типа, представленного объектом type_info. Этой функцией можно пользоваться в программах следующим образом:

#include <typeinfo>
int main() {
   employee *pe = new manager;

   // ia?aoaao: "manager"
   std::cout << typeid(*pe).name() << std::endl;
}

Для работы с функцией-членом name() нужно включить заголовочный файл <typeinfo>.

Имя типа – это единственная информация, которая гарантированно возвращается всеми реализациями C++, при этом используется функция-член name() класса type_info. В начале этого раздела упоминалось, что поддержка RTTI зависит от реализации и иногда в классе type_info бывают дополнительные функции-члены. Чтобы узнать, каким образом обеспечивается поддержка RTTI в вашем компиляторе, обратитесь к справочному руководству по нему. Кроме того, можно получить любую информацию, которую компилятор знает о типе, например:

список функций-членов класса;
способ размещения объекта в памяти, т.е. взаимное расположение подобъектов базового и производных классов.

Одним из способов расширения поддержки RTTI является включение дополнительной информации в класс, производный от type_info. Поскольку в классе type_info есть виртуальный деструктор, то оператор dynamic_cast позволяет выяснить, имеется ли некоторое конкретное расширение RTTI. Предположим, что некоторый компилятор предоставляет расширенную поддержку RTTI посредством класса extended_type_info, производного от type_info. С помощью оператора dynamic_cast программа может узнать, принадлежит ли объект типа type_info, возвращенный оператором typeid, к типу extended_type_info. Если да, то пользоваться расширенной поддержкой RTTI разрешено.

#include <typeinfo>

// Файл typeinfo содержит определение типа extended_type_info

void func(employee* p) {
   // понижающее приведение типа type_info* к extended_type_info*
   if (eti *eti_p = dynamic_cast<eti*>(&typeid(*p))) {
      // если dynamic_cast завершается успешно,
      // можно пользоваться информацией из extended_type_info через eti_p
   } else {
      // если dynamic_cast завершается неудачно,
      // можно пользоваться только стандартным type_info
   }
}

Если dynamic_cast завершается успешно, то оператор typeid вернет объект класса extended_type_info, т.е. компилятор обеспечивает расширенную поддержку RTTI, чем программа может воспользоваться. В противном случае допустимы только базовые средства RTTI.

Упражнение 19.1

Дана иерархия классов, в которой у каждого класса есть конструктор по умолчанию и виртуальный деструктор:

class X { ... };
class A { ... };
class B : public A { ... };
class C : public B { ... };
class D : public X, public C { ... };

Какие из данных операторов dynamic_cast завершатся неудачно?

(a) D *pd = new D;
    A *pa = dynamic_cast<A*>(pd);
(b) A *pa = new C;
    C *pc = dynamic_cast<C*>(pa);
(c) B *pb = new B;
    D *pd = dynamic_cast<D*>(pb);
(d) A *pa = new D;
    X *px = dynamic_cast<X*>(pa);

Упражнение 19.2: Объясните, когда нужно пользоваться оператором dynamic_cast вместо виртуальной функции?

Упражнение 19.3

Пользуясь иерархией классов из упражнения 19.1, перепишите следующий фрагмент так, чтобы в нем использовался ссылочный вариант dynamic_cast для преобразования *pa в тип D&:

if (D *pd = dynamic_cast<D*>(pa)) {
   // использовать члены D
}
else {
   // использовать члены A
}

Упражнение 19.4

Дана иерархия классов, в которой у каждого класса есть конструктор по умолчанию и виртуальный деструктор:

class X { ... };
class A { ... };
class B : public A { ... };
class C : public B { ... };
class D : public X, public C { ... };

Какое имя типа будет напечатано в каждом из следующих случаев:

(a) A *pa = new D;
    std::cout << typeid(pa).name() << std::endl;

(b) X *px = new D;
    std::cout << typeid(*px).name() << std::endl;

(c) C obj;
    A& ra = cobj;
    std::cout << typeid(&ra).name() << std::endl;

(d) X *px = new D;
    A& ra = *px;
    std::cout << typeid(ra).name() << std::endl;

§ 1.2. Исключения и наследование

Обработка исключений – это стандартное языковое средство для реакции на аномальное поведение программы во время выполнения. C++ поддерживает единообразный синтаксис и стиль обработки исключений, а также способы тонкой настройки этого механизма в специальных ситуациях. Основы его поддержки в языке C++ описаны в главе 11, где показано, как программа может возбудить исключение, передать управление его обработчику (если таковой существует) и как обработчики исключений ассоциируются с try-блоками.

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

19.2.1. Исключения, определенные как иерархии классов

В главе 11 мы использовали два типа класса для описания исключений, возбуждаемых функциями-членами нашего класса iStack:

class popOnEmpty { ... };
class pushOnFull { ... };

В реальных программах на C++ типы классов, представляющих исключения, чаще всего организуются в группы, или иерархии. Как могла бы выглядеть вся иерархия для этих классов?

Мы можем определить базовый класс Excp, которому наследуют оба наши класса исключений. Он инкапсулирует данные и функции-члены, общие для обоих производных:

class Excp { ... };
class popOnEmpty : public Excp { ... };
class pushOnFull : public Excp { ... };

Одной из операцией, которые предоставляет базовый класс, является вывод сообщения об ошибке. Эта возможность используется обоими классами, стоящими ниже в иерархии:

class Excp {
public:
   // напечатать сообщение об ошибке
   static void print(string msg) {
      std::cerr << msg << std::endl;
   }
};

Иерархию классов исключений разрешается развивать и дальше. От Excp можно произвести другие классы для более точного описания исключений, обнаруживаемых программой:

class Excp { ... };

class stackExcp : public Excp { ... };
   class popOnEmpty : public stackExcp { ... };
   class pushOnFull : public stackExcp { ... };

class mathExcp : public Excp (... };
   class zeroOp : public mathExcp { ... };
   class divideByZero : public mathExcp { ... };

Последующие уточнения позволяют более детально идентифицировать аномальные ситуации в работе программы. Дополнительные классы исключений организуются как слои. По мере углубления иерархии каждый новый слой описывает все более специфичные исключения. Например, первый, самый общий слой в приведенной выше иерархии представлен классом Excp. Второй специализирует Excp, выделяя из него два подкласса: stackExcp (для исключений при работе с нашим iStack) и mathExcp (для исключений, возбуждаемых функциями из математической библиотеки). Третий, самый специализированный слой данной иерархии уточняет классы исключений: popOnEmpty и pushOnFull определяют два вида исключений работы со стеком, а ZeroOp и divideByZero – два вида исключений математических операций.

В последующих разделах мы рассмотрим, как возбуждаются и обрабатываются исключения, представленные классами в нашей иерархии.

19.2.2. Возбуждение исключения типа класса

Теперь, познакомившись с классами, посмотрим, что происходит, когда функция-член push() нашего iStack возбуждает исключение:

void iStack::push(int value) {
   if (full())
      // value сохраняется в объекте-исключении
      throw pushOnFull(value);
   // ...
}

Выполнение инструкции throw инициирует несколько последовательных действий:

Инструкция throw создает временный объект типа класса pushOnFull, вызывая его конструктор.
С помощью копирующего конструктора генерируется объект-исключение типа pushOnFull – копия временного объекта, полученного на шаге 1. Затем он передается обработчику исключения.
Временный объект, созданный на шаге 1, уничтожается до начала поиска обработчика.

Зачем нужно генерировать объект-исключение (шаг 2)? Инструкция

throw pushOnFull(value);

создает временный объект, который уничтожается в конце работы throw. Но исключение должно существовать до тех пор, пока не будет найден его обработчик, а он может находиться намного выше в цепочке вызовов. Поэтому необходимо скопировать временный объект в некоторую область памяти (объект-исключение), которая гарантированно существует, пока исключение не будет обработано. Иногда компилятор создает объект-исключение сразу, минуя шаг 1. Однако стандарт этого не требует, да и не всегда такое возможно.

Поскольку объект-исключение создается путем копирования значения, переданного инструкции throw, то возбужденное исключение всегда имеет такой же тип, как и это значение:

void iStack::push(int value) {
   if (full()) {
      pushOnFull except(value);
      stackExcp *pse = &except;
      throw *pse;   // объект-исключение имеет тип stackExcp
   }
   // ...
}

Выражение *pse имеет тип stackExcp. Тип созданного объекта-исключения – stackExcp, хотя pse ссылается на объект с фактическим типом pushOnFull. Фактический тип объекта, на который ссылается throw, при создании объекта-исключения не учитывается. Поэтому исключение не будет перехвачено catch-обработчиком pushOnFull.

Действия, выполняемые инструкцией throw, налагают определенные ограничения на то, какие классы можно использовать для создания объектов-исключений. Оператор throw в функции-члене push() класса iStack вызовет ошибку компиляции, если:

в классе pushOnFull нет конструктора, принимающего аргумент типа int, или этот конструктор недоступен;
в классе pushOnFull есть копирующий конструктор или деструктор, но хотя бы один из них недоступен;
pushOnFull – это абстрактный базовый класс. Напомним, что программа не может создавать объекты абстрактных классов (см. раздел 17.1).

19.2.3. Обработка исключения типа класса

Если исключения организуются в иерархии, то исключение типа некоторого класса может быть перехвачено обработчиком, соответствующим любому его открытому базовому классу. Например, исключение типа pushOnFull перехватывается обработчиками исключений типа stackExcp или Excp.

int main() {
   try {
      // ...
   }
   catch (Excp) {
      // обрабатывает исключения popOnEmpty и pushOnFull
   }
   catch (pushOnFull) {
      // обрабатывает исключение pushOnFull
   }

Здесь порядок catch-обработчиков желательно изменить. Напоминаем, что они просматриваются в порядке появления после try-блока. Как только будет найден обработчик, способный обработать данное исключение, поиск прекращается. В примере выше Excp может обработать исключения типа pushOnFull, а это значит, что специализированный обработчик таких исключений задействован не будет. Правильная последовательность такова:

catch (pushOnFull) {
   // обрабатывает исключение pushOnFull
}
catch (Excp) {
   // обрабатывает другие исключения
}

catch-обработчик для производного класса должен идти первым. Тогда catch-обработчик для базового класса получит управление только в том случае, если более специализированного обработчика не нашлось.

Если исключения организованы в иерархии, то пользователи библиотеки классов могут выбрать в своем приложении уровень детализации при работе с исключениями, возбужденными внутри библиотеки. Например, кодируя функцию main(), мы решили, что исключения типа pushOnFull должны обрабатываться несколько иначе, чем прочие, и потому написали для них специализированный catch-обработчик. Что касается остальных исключений, то они обрабатываются единообразно:

catch (pushOnFull eObj) {
   // используется функция-член value() класса pushOnFull
   std::cerr << "попытка поместить значение " << eObj.value() << " в полный стек\n";
}
catch (Excp) {
   // используется функция-член print() базового класса
   Excp::print("произошло исключение");
}

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

Объявление исключения в catch-обработчике (находящееся в скобках после слова catch) очень похоже на объявление параметра функции. В приведенном примере оно напоминает параметр, передаваемый по значению. Объект eObj инициализируется копией значения объекта-исключения точно так же, как передаваемый по значению формальный параметр функции инициализируется значением фактического аргумента. Как и в случае с параметрами функции, в объявлении исключения можно использовать ссылки. Тогда catch-обработчик имеет доступ непосредственно к объекту-исключению, созданному выражением throw, а не к его локальной копии. Чтобы избежать копирования больших объектов, параметры типа класса следует объявлять как ссылки; в объявлениях исключений тоже желательно делать исключения типа класса ссылками. В зависимости от того, что находится в таком объявлении (объект или ссылка), поведение обработчика различается (мы покажем эти различия в данном разделе).

Пусть мы хотим повторно возбудить исключение, которое используется в catch-обработчике для передачи исключения какому-то другому обработчику выше в цепочке вызовов. Такое выражение имеет вид:

throw;

Как ведет себя эта инструкция, если она расположена в catch-обработчике исключений базового класса? Например, каким будет тип повторно возбужденного исключения, если mathFunc() возбуждает исключение типа divideByZero?

void calculate(int parm) {
   try {
      mathFunc(parm);  // возбуждает исключение divideByZero
   }
   catch (mathExcp mExcp) {
      // частично обрабатывает исключение
      // и генерирует объект-исключение еще раз
      throw;
   }
}

Будет ли повторно возбужденное исключение иметь тип divideByZero –тот же, что и исключение, возбужденное функцией mathFunc()? Или тип mathExcp, который указан в объявлении исключения в catch-обработчике?

Напомним, что выражение throw повторно генерирует исходный объект-исключение. Так как исходный объект имеет тип divideByZero, то повторно возбужденное исключение будет такого же типа. В catch-обработчике объект mExcp инициализируется копией подобъекта объекта типа divideByZero, который соответствует его базовому классу MathExcp. Доступ к ней осуществляется только внутри catch-обработчика, она не является исходным объектом-исключением, который повторно генерируется.

Предположим, что классы в нашей иерархии исключений имеют деструкторы:

class pushOnFull {
public:
   pushOnFull(int i) : _value(i) { }
   int value() { return _value; }
   ~pushOnFull();  // вновь объявленный деструктор
private:
   int _value;
};

Когда они вызываются? Чтобы ответить на этот вопрос, рассмотрим catch-обработчик:

catch (pushOnFull eObj) {
   std::cerr << "попытка поместить значение " <<eObj.value() << " в полный стек\n";
}

Поскольку в объявлении исключения eObj объявлен как локальный для catch-обработчика объект, а в классе pushOnFull есть деструктор, то eObj уничтожается при выходе из обработчика. Когда же вызывается деструктор для объекта-исключения, созданного в момент возбуждения исключения, – при входе в catch-обработчик или при выходе из него? Однако уничтожать исключение в любой из этих точек может быть слишком рано. Можете сказать, почему? Если catch-обработчик возбуждает исключение повторно, передавая его выше по цепочке вызовов, то уничтожать объект-исключение нельзя до момента выхода из последнего catch-обработчика.

19.2.4. Объекты-исключения и виртуальные функции

Если сгенерированный объект-исключение имеет тип производного класса, а обрабатывается catch-обработчиком для базового, то этот обработчик не может использовать особенности производного класса. Например, к функции-члену value(), которая объявлена в классе pushOnFull, нельзя обращаться в catch-обработчике Excp:

catch (const Excp &eObj) {
   // ошибка: в классе Excp нет функции-члена value()
   std::cerr << "попытка поместить значение " << eObj.value() << " в полный стек\n";
}

Но мы можем перепроектировать иерархию классов исключений и определить виртуальные функции, которые можно вызывать из catch-обработчика для базового класса Excp с целью получения доступа к функциям-членам более специализированного производного:

// новые определения классов, включающие виртуальные функции
class Excp {
public:
   virtual void print(string msg) {
      std::cerr << "Произошло исключение" << std::endl;
   }
};
class stackExcp : public Excp { };
class pushOnFull : public stackExcp {
public:
   void print() override {
      std::cerr << "попытка поместить значение " << _value << " в полный стек\n";
   }
   // ...
};

Функцию print() теперь можно использовать в catch-обработчике следующим образом:

int main() {
   try {
      // iStack::push() возбуждает исключение pushOnFull
   } catch (Excp eObj) {
     eObj.print();    // хотим вызвать виртуальную функцию,
                      // но вызывается экземпляр из базового класса
   }
}

Хотя возбужденное исключение имеет тип pushOnFull, а функция print() виртуальна, инструкция eObj.print() печатает такую строку:

Произошло исключение

Вызываемая print() является членом базового класса Excp, а не замещает ее в производном. Но почему?

Вспомните, что объявление исключения в catch-обработчике ведет себя почти так же, так объявление параметра. Когда управление попадает в catch-обработчик, то, поскольку в нем объявлен объект, а не ссылка, eObj инициализируется копией подобъекта Excp базового класса объекта исключения. Поэтому eObj – это объект типа Excp, а не pushOnFull. Чтобы вызвать виртуальные функции из производных классов, в объявлении исключения должен быть указатель или ссылка:

int main() {
   try {
      // iStack::push() возбуждает исключение pushOnFull
   } catch (const Excp &eObj) {
     eObj.print();   // вызывается виртуальная функция
                      // pushOnFull::print()
   }
}

Объявление исключения в этом примере тоже относится к базовому классу Excp, но так как eObj – ссылка и при этом именует объект-исключение типа pushOnFull, то для нее можно вызывать виртуальные функции, определенные в классе pushOnFull. Когда catch-обработчик обращается к виртуальной функции print(), вызывается функция из производного класса, и программа печатает следующую строку:

попытка поместить значение 879 в полный стек

Таким образом, ссылка в объявлении исключения позволяет вызывать виртуальные функции, ассоциированные с классом объекта-исключения.

19.2.5. Раскрутка стека и вызов деструкторов

Когда возбуждается исключение, поиск его catch-обработчика (раскрутка стека) начинается с функции, возбудившей исключение, и продолжается вверх по цепочке вложенных вызовов.

Во время раскрутки поочередно происходят аномальные выходы из просмотренных функций. Если функция захватила некоторый ресурс (например, открыла файл или выделила из хипа память), он в таком случае не освобождается.

Существует прием, позволяющий решить эту проблему. Всякий раз, когда во время поиска обработчика происходит выход из составной инструкции или блока, где определен некоторый локальный объект, для этого объекта автоматически вызывается деструктор. (Локальные объекты рассматривались в разделе 8.1.)

Например, следующий класс инкапсулирует выделение памяти для массива целых в конструкторе и ее освобождение в деструкторе:

class PTR {
public:
   PTR() { ptr = new int[chunk]; }
   ~PTR { delete[] ptr; }
private:
   int *ptr;
};

Локальный объект такого типа создается в функции manip() перед вызовом mathFunc():

void manip(int parm) {
   PTR localPtr;
   // ...
   mathFunc(parm);   // возбуждает исключение divideByZero
   // ...
}

Если mathFunc() возбуждает исключение типа divideByZero, то начинается раскрутка стека. В процессе поиска подходящего catch-обработчика проверяется и функция manip(). Поскольку вызов mathFunc() не заключен в try-блок, то manip() нужного обработчика не содержит. Поэтому стек раскручивается дальше по цепочке вызовов. Но перед выходом из manip() с необработанным исключением процесс раскрутки уничтожает все объекты типа классов, которые локальны в ней и были созданы до вызова mathFunc(). Таким образом, локальный объект localPtr уничтожается до того, как поиск пойдет дальше, а следовательно, память, на которую он указывает, будет освобождена и утечки не произойдет.

Поэтому говорят, что процесс обработки исключений в C++ поддерживает технику программирования, основной принцип которой можно сформулировать так: захват ресурса – это инициализация; освобождение ресурса – это уничтожение. Если ресурс реализован в виде класса и, значит, действия по его захвату сосредоточены в конструкторе, а действия по освобождению – в деструкторе (как, например, в классе PTR выше), то локальный для функции объект такого класса автоматически уничтожается при выходе из функции в результате необработанного исключения. Действия, которые должны быть выполнены для освобождения ресурса, не будут пропущены при раскрутке стека, если они инкапсулированы в деструкторы, вызываемые для локальных объектов.

Класс auto_ptr, определенный в стандартной библиотеке (см. раздел 8.4), ведет себя почти так же, как наш класс PTR. Это средство для инкапсуляции выделения памяти в конструкторе и ее освобождения в деструкторе. Если для выделения одиночного объекта из хипа используется auto_ptr, то гарантируется, что при выходе из составной инструкции или функции из-за необработанного исключения память будет освобождена.

19.2.6. Спецификации исключений

С помощью спецификации исключений в объявлении функции указывается множество исключений, которые она может возбуждать прямо или косвенно. Спецификация позволяет гарантировать, что функция не возбудит не перечисленные в ней исключения.

Такую спецификацию разрешается задавать для функций-членов класса так же, как и для обычных функций; она должна следовать за списком параметров функции-члена. Например, в определении класса bad_alloc из стандартной библиотеки C++ функции-члены имеют пустую спецификацию исключений throw(), т.е. гарантированно не возбуждают никаких исключений:

class bad_alloc : public exception {
   // ...
public:
   bad_alloc() throw();
   bad_alloc(const bad_alloc &) throw();
   bad_alloc& operator=(const bad_alloc&) throw();
   virtual ~bad_alloc() throw();
   virtual const char* what() const throw();
};

Отметим, что если функция-член объявлена с модификатором const или volatile, как, скажем, what() в примере выше, то спецификация исключений должна идти после него.

Во всех объявлениях одной и той же функции спецификации исключений обязаны содержать одинаковые типы. Если речь идет о функции-члене, определение которой находится вне определения класса, то спецификации исключений в этом определении и в объявлении функции должны совпадать:

#include <stdexcept>
// <stdexcept> определяет класс overflow_error

class transport {
   // ...
public:
   double cost(double, double) throw (overflow_error);
   // ...
};

// ошибка: спецификация исключений отличается от той, что задана
//         в объявлении в списке членов класса
double transport::cost(double rate, double distance) { }

Виртуальная функция в базовом классе может иметь спецификацию исключений, отличающуюся от той, что задана для замещающей функции-члена в производном. Однако в производном классе эта спецификация для виртуальной функции должна накладывать не меньше ограничений, чем в базовом:

class Base {
public:
   virtual double f1(double) throw();
   virtual int f2(int) throw(int);
   virtual string f3() throw(int, string);
   // ...
}
class Derived : public Base {
public:
   // ошибка: спецификация исключений накладывает меньше ограничений,
   //         чем на Base::f1()
   double f1(double) throw(string);

   // правильно: та же спецификация исключений, что и для Base::f2()
   int f2(int) throw(int);

   // правильно: спецификация исключений f3() накладывает больше ограничений
   string f3() throw(int);
   // ...
};

Почему спецификация исключений в производном классе должна накладывать не меньше ограничений, чем в базовом? В этом случае мы можем быть уверены, что вызов виртуальной функции из производного класса по указателю на тип базового не нарушит спецификацию исключений функции-члена базового класса:

// гарантируется, что исключения возбуждены не будут
void compute(Base *pb) throw() {
   try {
      pb->f3();  // может возбудить исключение типа int или string
   }
   // обработка исключений, возбужденных в Base::f3()
   catch (const string&) { }
   catch (int) { }
}

Объявление f3() в классе Base гарантирует, что эта функция возбуждает лишь исключения типа int или string. Следовательно, функция compute() включает catch-обработчики только для них. Поскольку спецификация исключений f3() в производном классе Derived накладывает больше ограничений, чем в базовом Base, то при программировании в согласии с интерфейсом класса Base наши ожидания не будут обмануты.

Ранее говорилось, что между типом возбужденного исключения и типом, заданным в спецификации исключений, не допускаются никакие преобразования. Однако если там указан тип класса, то функция может возбуждать исключения в виде объекта класса, открыто наследующего заданному. Аналогично, если имеется указатель на класс, то функции разрешено возбуждать исключения в виде указателя на объект класса, открыто наследующего заданному. Например:

class stackExcp : public Excp { };
class popObEmpty : public stackExcp { };

class pushOnFull : public stackExcp { };

void stackManip() throw(stackExcp)
{
   // ...
}

Спецификация исключений указывает, что stackManip() может возбуждать исключения не только типа stackExcp, но также popOnEmpty и pushOnFull. Напомним, что класс, открыто наследующий базовому, представляет собой пример отношения ЯВЛЯЕТСЯ, т.е. является частным случае более общего базового класса. Поскольку popOnEmpty и pushOnFull – частные случаи stackExcp, они не нарушают спецификации исключений функции stackManip().

19.2.7. Конструкторы и функциональные try-блоки

Можно объявить функцию так, что все ее тело будет заключено в try-блок. Такие try-блоки называются функциональными. (Мы упоминали их в разделе 11.2.) Например:

int main() {
try {
   // тело функции main()
}
catch (pushOnFull) {
   // ...
}
catch (popOnEmpty) {
   // ...
}

Функциональный try-блок ассоциирует группу catch-обработчиков с телом функции. Если инструкция внутри тела возбуждает исключение, то поиск его обработчика ведется среди тех, что следуют за телом функции.

Функциональный try-блок необходим для конструкторов класса. Почему? Определение конструктора имеет следующий вид:

имя_класса(список_параметров)

// список инициализации членов:
: член1(выражение1) ,    // инициализация член1
  член2(выражение2) ,    // инициализация член2
// тело функции:
{ /* ... */ }

выражение1 и выражение2 могут быть выражениями любого вида, в частности функциями, которые возбуждают исключения.

Рассмотрим еще раз класс Account, описанный в главе 14. Его конструктор можно переопределить так:

inline Account::Account(const char* name, double opening_bal)
   : _balance(opening_bal - ServiceCharge())
{
   _name = new char[strlen(name) + 1];
   strcpy(_name, name);

   _acct_nmbr = get_unique_acct_nmbr();
}

Функция ServiceCharge(), вызываемая для инициализации члена _balance, может возбуждать исключение. Как нужно реализовать конструктор, если мы хотим обрабатывать все исключения, возбуждаемые функциями, которые вызываются при конструировании объекта типа Account?

Помещать try-блок в тело функции нельзя:

inline Account::Account(const char* name, double opening_bal)
   : _balance(opening_bal - ServiceCharge())
{
   try {
      _name = new char[strlen(name) + 1];
      strcpy(_name, name);
      _acct_nmbr = get_unique_acct_nmbr();
   }
   catch (...) {
      // специальная обработка
      // не перехватывает исключения,
      // возбужденные в списке инициализации членов
   }
}

Поскольку try-блок не охватывает список инициализации членов, то catch-обработчик, находящийся в конце конструктора, не рассматривается при поиске кандидатов, которые способны перехватить исключение, возбужденное в функции ServiceCharge().

Использование функционального try-блока – это единственное решение, гарантирующее, что все исключения, возбужденные при создании объекта, будут перехвачены в конструкторе. Для конструктора класса Account такой try-блок можно определить следующим образом:

inline Account::Account(const char* name, double opening_bal)
   : _balance(opening_bal - ServiceCharge())
{
try {
   _name = new char[strlen(name) + 1];
   strcpy(_name, name);
   _acct_nmbr = get_unique_acct_nmbr();
}
catch (...) {
   // теперь специальная обработка
   // перехватывает исключения,
   // возбужденные в ServiceCharge()
}
}

Обратите внимание, что ключевое слово try находится перед списком инициализации членов, а составная инструкция, образующая try-блок, охватывает тело конструктора. Теперь предложение catch(...) принимается во внимание при поиске обработчика исключения, возбужденного как в списке инициализации членов, так и в теле конструктора.

19.2.8. Иерархия классов исключений в стандартной библиотеке C++

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

Корневой класс исключения в стандартной иерархии называется exception. Он определен в стандартном заголовочном файле <exception> и является базовым для всех исключений, возбуждаемых функциями из стандартной библиотеки. Класс exception имеет следующий интерфейс:

namespace std {
   class exception
   public:
      exception() throw();
      exception(const exception&) throw();
      exception& operator=(const exception &) throw();
      virtual ~exception() throw();
      virtual const char* what() const throw();
   };
}

Как и всякий другой класс из стандартной библиотеки C++, exception помещен в пространство имен std, чтобы не засорять глобальное пространство имен программы.

Первые четыре функции-члена в определении класса – это конструктор по умолчанию, копирующий конструктор, копирующий оператор присваивания и деструктор. Поскольку все они открыты, любая программа может свободно создавать и копировать объекты-исключения, а также присваивать им значения. Деструктор объявлен виртуальным, чтобы сделать возможным дальнейшее наследование классу exception.

Самой интересной в этом списке является виртуальная функция what(), которая возвращает C-строку с текстовым описанием возбужденного исключения. Классы, производные от exception, могут заместить what() собственной версией, которая лучше характеризует объект-исключение.

Отметим, что все функции в определении класса exception имеют пустую спецификацию throw(), т.е. не возбуждают никаких исключений. Программа может манипулировать объектами-исключениями (к примеру, внутри catch-обработчиков типа exception), не опасаясь, что функции создания, копирования и уничтожения этих объектов возбудят исключения.

Помимо корневого exception, в стандартной библиотеке есть и другие классы, которые допустимо использовать в программе для извещения об ошибках, обычно подразделяемых на две больших категории: логические ошибки и ошибки времени выполнения.

Логические ошибки обусловлены нарушением внутренней логики программы, например логических предусловий или инвариантов класса. Предполагается, что их можно найти и предотвратить еще до начала выполнения программы. В стандартной библиотеке определены следующие такие ошибки:

namespace std {
   class logic_error : public exception {  // логическая ошибка
   public:
      explicit logic_error(const string &what_arg);
   };
   class invalid_argument : public logic_error { // неверный аргумент
   public:
      explicit invalid_argument(const string &what_arg);
   };
   class out_of_range : public logic_error { // вне диапазона
   public:
      explicit out_of_range(const string &what_arg);
   };
   class length_error : public logic_error { // неверная длина
   public:
      explicit length_error(const string &what_arg);
   };
   class domain_error : public logic_error { // вне допустимой области
   public:
      explicit domain_error(const string &what_arg);
   };
}

Функция может возбудить исключение invalid_argument, если получит аргумент с некорректным значением; в конкретной ситуации, когда значение аргумента выходит за пределы допустимого диапазона, разрешается возбудить исключение out_of_range, а length_error используется для оповещения о попытке создать объект, длина которого превышает максимально возможную.

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

namespace std {
   class runtime_error : public exception {  // ошибка времени выполнения
   public:
      explicit runtime_error(const string &what_arg);
   };
   class range_error : public runtime_error { // ошибка диапазона
   public:
      explicit range_error(const string &what_arg);
   };
   class overflow_error : public runtime_error { // переполнение
   public:
      explicit overflow_error(const string &what_arg);
   };
   class underflow_error : public runtime_error { // потеря значимости
   public:
      explicit underflow_error(const string &what_arg);
   };
}

Функция может возбудить исключение range_error, чтобы сообщить об ошибке во внутренних вычислениях. Исключение overflow_error говорит об ошибке арифметического переполнения, а underflow_error – о потере значимости.

Класс exception является базовым и для класса исключения bad_alloc, которое возбуждает оператор new(), когда ему не удается выделить запрошенный объем памяти (см. раздел 8.4), и для класса исключения bad_cast, возбуждаемого в ситуации, когда ссылочный вариант оператора dynamic_cast не может быть выполнен (см. раздел 19.1).

Переопределим оператор operator[] в шаблоне Array из раздела 16.12 так, чтобы он возбуждал исключение типа range_error, если индекс массива Array выходит за границы:

#include <stdexcept>
#include <string>

template <class elemType>
class Array {
public:
   // ...
   elemType& operator[](int ix) const {
      if (ix < 0 || ix >= _size) {
         string eObj = "ошибка: вне диапазона в Array<elemType>::operator[]() ";

         throw out_of_range(eObj);
      }
      return _ia[ix];
   }

   // ...
private:
   int _size;
   elemType *_ia;
};

Для использования предопределенных классов исключений в программу необходимо включить заголовочный файл <stdexcept>. Описание возбужденного исключения содержится в объекте eObj типа string. Эту информацию можно извлечь в обработчике с помощью функции-члена what():

int main() {
   try {
      // функция main() такая же, как в разделе 16.2
   }
   catch (const out_of_range &excep) {
      // печатается:
      // ошибка: вне диапазона в Array<elemType>::operator[]()
      std::cerr << excep.what() << "\n ";
      return -1;
   }
}

В данной реализации выход индекса за пределы массива в функции try_array() приводит к тому, что оператор взятия индекса operator[]() класса Array возбуждает исключение типа out_of_range, которое перехватывается в main().

Упражнение 19.5

Какие исключения могут возбуждать следующие функции:

#include <stdexcept>
(a) void operate() throw(logic_error);
(b) int mathErr(int) throw(underflow_error, overflow_error);
(c) char manip(string) throw();

Упражнение 19.6: Объясните, как механизм обработки исключений в C++ поддерживает технику программирования"захват ресурса – это инициализация; освобождение ресурса – это уничтожение".

Упражнение 19.7: Исправьте ошибку в списке catch-обработчиков для данного try-блока:

#include <stdexcept>

int main() {
   try {
      // использование функций из стандартной библиотеки
   }
   catch(exception) {
   }
   catch(runtime_error &re) {
   }
   catch(overflow_error eobj) {
   }
}

Упражнение 19.8

Дана программа на C++:

int main() {
   // использование стандартной библиотеки
}

Модифицируйте main() так, чтобы она перехватывала все исключения, возбуждаемые функциями стандартной библиотеки. Обработчики должны печатать сообщение об ошибке, ассоциированное с исключением, а затем вызывать функцию abort() (она определена в заголовочном файле <cstdlib>) для завершения main().

§ 1.3. Разрешение перегрузки и наследование

Наследование классов оказывает влияние на все аспекты разрешения перегрузки функций. Напомним, что эта процедура состоит из трех шагов:

Отбор функций-кандидатов.
Отбор устоявших функций.
Выбор наилучшей из устоявших функции.

Отбор функций-кандидатов зависит от наследования потому, что на этом шаге принимаются во внимание функции, ассоциированные с базовыми классами, – как их функции-члены, так и функции, объявленные в тех же пространствах имен, где определены базовые классы. Отбор устоявших функций также зависит от наследования, поскольку множество преобразований формальных параметров функции в фактические аргументы расширяется пользовательскими преобразованиями. Кроме того, наследование оказывает влияние на ранжирование последовательностей трансформаций аргументов, а значит, и на выбор наилучшей из устоявших функции. В данном разделе мы рассмотрим влияние наследования на эти три шага разрешения перегрузки более подробно.

19.3.1. Функции-кандидаты

Наследование влияет на первый шаг процедуры разрешения перегрузки функции – формирование множества кандидатов для данного вызова, причем это влияние может быть различным в зависимости от того, рассматривается ли вызов обычной функции вида

func(args);

или функции-члена с помощью операторов доступа "точка" или "стрелка":

object.memfunc(args);
pointer->memfunc(args);

В данном разделе мы изучим оба случая.

Если аргумент обычной функции имеет тип класса, ссылки или указателя на тип класса, и класс определен в пространстве имен, то кандидатами будут все одноименные функции, объявленные в этом пространстве, даже если они невидимы в точке вызова (подробнее об этом говорилось в разделе 15.10). Если аргумент при наследовании имеет тип класса, ссылки или указателя на тип класса, и у этого класса есть базовые, то в множество кандидатов добавляются также функции, объявленные в тех пространствах имен, где определены базовые классы. Например:

namespace NS {
   class ZooAnimal { /* ... */ };
   void display(const ZooAnimal&);
}

// базовый класс Bear объявлен в пространстве имен NS
class Bear : public NS::ZooAnimal { };

int main() {
   Bear baloo;

   display(baloo);
   return 0;
}

Аргумент baloo имеет тип класса Bear. Кандидатами для вызова display() будут не только функции, объявления которых видимы в точке ее вызова, но также и те, что объявлены в пространствах имен, в которых объявлены класс Bear и его базовый класс ZooAnimal. Поэтому в множество кандидатов добавляется функция display(const ZooAnimal&), объявленная в пространстве имен NS.

Если аргумент имеет тип класса и в определении этого класса объявлены функции-друзья с тем же именем, что и вызванная функция, то эти друзья также будут кандидатами, даже если их объявления не видны в точке вызова (см. раздел 15.10). Если аргумент при наследовании имеет тип класса, у которого есть базовые, то в множество кандидатов добавляются одноименные функции-друзья каждого из них. Предположим, что в предыдущем примере display() объявлена как функция-друг ZooAnimal:

namespace NS {
   class ZooAnimal {
      friend void display(const ZooAnimal&);
   };
}

// базовый класс Bear объявлен в пространстве имен NS
class Bear : public NS::ZooAnimal { };

int main() {
   Bear baloo;

   display(baloo);
   return 0;
}

Аргумент baloo функции display() имеет тип Bear. В его базовом классе ZooAnimal функция display() объявлена другом, поэтому она является членом пространства имен NS, хотя явно в нем не объявлена. При обычном просмотре NS она не была бы найдена. Однако поскольку аргумент display() имеет тип Bear, то объявленная в ZooAnimal функция-друг добавляется в множество кандидатов.

Таким образом, если при вызове обычной функции задан аргумент, который представляет собой объект класса, ссылку или указатель на объект класса, то множество функций-кандидатов является объединением следующих множеств:

функций, видимых в точке вызова;
функций, объявленных в тех пространствах имен, где определен тип класса или любой из его базовых;
функций, являющихся друзьями этого класса или любого из его базовых.

Наследование влияет также на построение множества кандидатов для вызова функции-члена с помощью операторов "точка" или "стрелка". В разделе 18.4 мы говорили, что объявление функции-члена в производном классе не перегружает, а скрывает одноименные функции-члены в базовом, даже если их списки параметров различны:

class ZooAnimal {
public:
   Time feeding_time(string);
   // ...
};
class Bear : public ZooAnimal {
public:
   // скрывает ZooAnimal::feeding_time(string)
   Time feeding_time(int);
   // ...
};

Bear Winnie;

// ошибка: ZooAnimal::feeding_time(string) скрыта
Winnie.feeding_time("Winnie");

Функция-член feeding_time(int), объявленная в классе Bear, скрывает feeding_time(string), объявленную в ZooAnimal, базовом для Bear. Поскольку функция-член вызывается через объект Winnie типа Bear, то при поиске кандидатов для этого вызова просматривается только область видимости класса Bear, и единственным кандидатом будет feeding_time(int). Так как других кандидатов нет, вызов считается ошибочным.

Чтобы исправить ситуацию и заставить компилятор считать одноименные функции-члены базового и производного классов перегруженными, разработчик производного класса может ввести функции-члены базового класса в область видимости производного с помощью using-объявлений:

class Bear : public ZooAnimal {
public:
   // feeding_time(int) перегружает экземпляр из класса ZooAnimal
   using ZooAnimal::feeding_time;
   Time feeding_time(int);
   // ...
};

Теперь обе функции feeding_time() находятся в области видимости класса Bear и, следовательно, войдут в множество кандидатов:

// правильно: вызывается ZooAnimal::feeding_time(string)
Winnie.feeding_time("Winnie");

В такой ситуации вызывается функция-член feeding_time(string).

В случае множественного наследования при формировании совокупности кандидатов объявления функций-членов должны быть найдены в одном и том же базовом классе, иначе вызов считается ошибочным. Например:

class Endangered {
public:
   std::ostream& print(std::ostream&);
   // ...
};

class Bear : public(ZooAnimal) {
public:
   void print();
   using ZooAnimal::feeding_time;
   Time feeding_time(int);
   // ...
};

class Panda : public Bear, public Endangered {
public:
   // ...
};

int main() {
   Panda yin_yang;

   // ошибка: неоднозначность: одна из
   //         Bear::print()
   //         Endangered::print(std::ostream&)
   yin_yang.print(std::cout);

   // правильно: вызывается Bear::feeding_time()
   yin_yang.feeding_time(56);
}

При поиске объявления функции-члена print() в области видимости класса Panda будут найдены как Bear::print(), так и Endangered::print(). Поскольку они не находятся в одном и том же базовом классе, то даже при разных списках параметров этих функций множество кандидатов оказывается пустым и вызов считается ошибочным. Для исправления ошибки в классе Panda следует определить собственную функцию print(). При поиске объявления функции-члена feeding_time() в области видимости Panda будут найдены ZooAnimal::feeding_time() и Bear::feeding_time() – они расположены в области видимости класса Bear. Так как эти объявления найдены в одном и том же базовом классе, множество кандидатов для данного вызова включает обе функции, а выбирается Bear::feeding_time().

19.3.2. Устоявшие функции и последовательности пользовательских преобразований

Наследование оказывает влияние и на второй шаг разрешения перегрузки функции: отбор устоявших из множества кандидатов. Устоявшей называется функция, для которой существуют приведения типа каждого фактического аргумента к типу соответственного формального параметра.

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

Конвертеры наследуются, как и любые другие функции-члены класса. Например, мы можем написать следующий конвертер для ZooAnimal:

class ZooAnimal {
public:

   // конвертер: ZooAnimal ==> const char*
   operator const char*();

   // ...
};

Производный класс Bear наследует его от своего базового ZooAnimal. Если значение типа Bear используется в контексте, где ожидается const char*, то неявно вызывается конвертер для преобразования Bear в const char*:

extern void display(const char*);

Bear yogi;

// правильно: yogi ==> const char*
display(yogi);

Конструкторы с одним аргументом без ключевого слова explicit образуют другое множество неявных преобразований: из типа параметра в тип своего класса. Определим такой конструктор для ZooAnimal:

class ZooAnimal {
public:
   // преобразование: int ==> ZooAnimal
   ZooAnimal(int);

   // ...
};

Его можно использовать для приведения значения типа int к типу ZooAnimal. Однако конструкторы не наследуются. Конструктор ZooAnimal нельзя применять для преобразования объекта в случае, когда целевым является тип производного класса:

const int cageNumber = 8788l

void mumble(const Bear&);

// ошибка: ZooAnimal(int) не используется
mumble(cageNumber);

Поскольку целевым типом является Bear – тип параметра функции mumble(), то рассматриваются только его конструкторы.

19.3.3. Наилучшая из устоявших функций

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

преобразование аргумента типа производного класса в параметр типа любого из его базовых;
преобразование указателя на тип производного класса в указатель на тип любого из его базовых;
инициализация ссылки на тип базового класса с помощью l-значения типа производного.

Они не являются пользовательскими, так как не зависят от конвертеров и конструкторов, имеющихся в классе:

extern void release(const ZooAnimal&);
Panda yinYang;

// стандартное преобразование: Panda -> ZooAnimal
release(yinYang);

Поскольку аргумент yinYang типа Panda инициализирует ссылку на тип базового класса, то преобразование имеет ранг стандартного.

В разделе 15.10 мы говорили, что стандартные преобразования имеют более высокий ранг, чем пользовательские:

class Panda : public Bear, public Endangered {
   // наследует ZooAnimal::operator const char *()
};

Panda yinYang;

extern void release(const ZooAnimal&);
extern void release(const char *);

// стандартное преобразование: Panda -> ZooAnimal
// выбирается: release(const ZooAnimal&)
release(yinYang);

Как release(const char*), так и release(ZooAnimal&) являются устоявшими функциями: первая потому, что инициализация параметра-ссылки значением аргумента – стандартное преобразование, а вторая потому, что аргумент можно привести к типу const char* с помощью конвертера ZooAnimal::operator const char*(), который представляет собой пользовательское преобразование. Так как стандартное преобразование лучше пользовательского, то в качестве наилучшей из устоявших выбирается функция release(const ZooAnimal&).

При ранжировании различных стандартных преобразований из производного класса в базовые лучшим считается приведение к тому базовому классу, который ближе к производному. Так, показанный ниже вызов не будет неоднозначным, хотя в обоих случаях требуется стандартное преобразование. Приведение к базовому классу Bear лучше, чем к ZooAnimal, поскольку Bear ближе к классу Panda. Поэтому лучшей из устоявших будет функция release(const Bear&):

extern void release(const ZooAnimal&);
extern void release(const Bear&);

// правильно: release(const Bear&)
release(yinYang);

Аналогичное правило применимо и к указателям. При ранжировании стандартных преобразований из указателя на тип производного класса в указатели на типы различных базовых лучшим считается то, для которого базовый класс наименее удален от производного. Это правило распространяется и на тип void*.

Стандартное преобразование в указатель на тип любого базового класса всегда лучше, чем преобразование в void*. Например, если дана пара перегруженных функций:

void receive(void*);
void receive(ZooAnimal*);

то наилучшей из устоявших для вызова с аргументом типа Panda* будет receive(ZooAnimal*).

В случае множественного наследования два стандартных преобразования из типа производного класса в разные типы базовых могут иметь одинаковый ранг, если оба базовых класса равноудалены от производного. Например, Panda наследует классам Bear и Endangered. Поскольку они равноудалены от производного Panda, то преобразования объекта Panda в любой из этих классов одинаково хороши. Но тогда единственной наилучшей из устоявших функции для следующего вызова не существует, и он считается ошибочным:

extern void mumble(const Bear&);
extern void mumble(const Endangered&);

/* ошибка: неоднозначный вызов:
 * может быть выбрана любая из двух функций
 * void mumble(const Bear&);
* void mumble(const Endangered&);
*/
mumble(yinYang);

Для разрешения неоднозначности программист может применить явное приведение типа:

mumble(static_cast<Bear>(yinYang));  // правильно

Инициализация объекта производного класса или ссылки на него объектом типа базового, а также преобразование указателя на тип базового класса в указатель на тип производного никогда не выполняются компилятором неявно. (Однако их можно выполнить с помощью явного применения dynamic_cast, как мы видели в разделе 19.1.) Для данного вызова не существует наилучшей из устоявших функции, так как нет неявного преобразования аргумента типа ZooAnimal в тип производного класса:

extern void release(const Bear&);
extern void release(const Panda&);

ZooAnimal za;

// ошибка: нет соответствия
release(za);

В следующем примере наилучшей из устоявших будет release(const char*). Это может показаться удивительным, так как к аргументу применена последовательность пользовательских преобразований, в которой участвует конвертер const char*(). Но поскольку неявного приведения от типа базового класса к типу производного не существует, то release(const Bear&) не является устоявшей функцией, так что остается только release(const char*):

Class ZooAnimal {
public:
   // преобразование: ZooAnimal ==> const char*
   operator const char*();

   // ...
};

extern void release(const char*);
extern void release(const Bear&);

ZooAnimal za;

// za ==> const char*
// правильно: release(const char*)
release(za);

Упражнение 19.9

Дана такая иерархия классов:

class Base1 {
public:
   std::ostream& print();
   void debug();
   void writeOn();
   void log(string);
   void reset(void *);
   // ...
};

class Base2 {
public:
   void debug();
   void readOn();
   void log(double);
   // ...
};

class MI : public Base1, public Base2 {
public:
   std::ostream& print();
   using Base1::reset;
   void reset(char *);
   using Base2::log;
   using Base2::log;
   // ...
};

Какие функции входят в множество кандидатов для каждого из следующих вызовов:

MI *pi = new MI;
(a) pi->print();
(b) pi->debug();
(c) pi->readOn();
(d) pi->reset(0);
(e) pi->log(num);
(f) pi->writeOn();

Упражнение 19.10

Дана такая иерархия классов:

class Base {
public:
   operator int();
   operator const char *();
   // ...
};
class Derived : public Base {
public:
   operator double();
   // ...
};

Удастся ли выбрать наилучшую из устоявших функций для каждого из следующих вызовов? Назовите кандидаты, устоявшие функции и преобразования типов аргументов для каждой из них, наилучшую из устоявших (если она есть):

(a) void operate(double);
    void operate(string);
    void operate(const Base &);

    Derived *pd = new Derived;
    operate(*pd);
(b) void calc(int);
    void calc(double);
    void calc(const Derived &);

    Base *pb = new Derived;
    operate(*pb);