Бьерн Страуструп (947334), страница 79
Текст из файла (страница 79)
классы.
13.5.3 Как создать систему динамических запросов о типе
Здесь показано, как можно прямо реализовать динамические запросы
о типе, когда в трансляторе таких возможностей нет. Это достаточно
утомительная задача и можно пропустить этот раздел, так как в нем
есть только детали конкретного решения.
Классы set и slist_set из $$13.3 следует изменить так, чтобы
с ними могли работать операции запросов о типе. Прежде всего, в
базовый класс set нужно ввести функции-члены, которые используют
операции запросов о типе:
class set {
public:
static const Type_info info_obj;
virtual typeid get_info() const;
static typeid info();
// ...
};
При выполнении программы единственным представителем объекта типа
set является set::info_obj, который определяется так:
const Type_info set::info_obj("set",0);
С учетом этого определения функции тривиальны:
typeid set::get_info() const { return &info_obj; }
typeid set::info() { return &info_obj; }
typeid slist_set::get_info() const { return &info_obj; }
typeid slist_set::info() { return &info_obj; }
Виртуальная функция get_info() будет предоставлять операции
ref_type_info() и ptr_type_info(), а статическая функция info()
- операцию static_type_info().
При таком построении системы запросов о типе основная трудность
на практике состоит в том, чтобы для каждого класса объект типа
Type_info и две функции, возвращающие указатель на этот объект,
определялись только один раз.
Нужно несколько изменить класс slist_set:
class slist_set : public set, private slist {
// ...
public:
static const Type_info info_obj;
virtual typeid get_info() const;
static typeid info();
// ...
};
static const Type_info* slist_set_b[]
= { &set::info_obj, &slist::info_obj, 0 };
const Type_info slist_set::info_obj("slist_set",slist_set_b);
typeid slist_set::get_info() const { return &info_obj; }
typeid slist_set::info() { return &info_obj; }
13.5.4 Расширенная динамическая информация о типе
В классе Type_info содержится только минимум информации, необходимой
для идентификации типа и безопасных операций приведения. Но поскольку
в самом классе Type_info есть функции-члены info() и get_info(),
можно построить производные от него классы, чтобы в динамике
определять, какие объекты Type_info возвращают эти функции. Таким
образом, не меняя класса Type_info, пользователь может получать
больше информации о типе с помощью объектов, возвращаемых функциями
dynamic_type() и static_type(). Во многих случаях дополнительная
информация должна содержать таблицу членов объекта:
struct Member_info {
char* name;
Type_info* tp;
int offset;
};
class Map_info : public Type_info {
Member_info** mi;
public:
static const Type_info info_obj;
virtual typeid get_info() const;
static typeid info();
// функции доступа
};
Класс Type_info вполне подходит для стандартной библиотеки. Это
базовый класс с минимумом необходимой информации, из которого
можно получать производные классы, предоставляющие больше информации.
Эти производные классы могут определять или сами пользователи, или
какие-то служебные программы, работающие с текстом на С++, или сами
трансляторы языка.
13.5.5 Правильное и неправильное использование динамической
информации о типе
Динамическая информация о типе может использоваться во многих
ситуациях, в том числе для: объектного ввода-вывода,
объектно-ориентированных баз данных, отладки. В тоже время
велика вероятность ошибочного использования такой информации.
Известно,что в языке Симула использование таких средств,
как правило, приводит к ошибкам. Поэтому эти средства не были
включены в С++. Слишком велик соблазн воспользоваться динамической
информацией о типе, тогда как правильнее вызвать виртуальную
функцию. Рассмотрим в качестве примера класс Shape из $$1.2.5.
Функцию rotate можно было задать так:
void rotate(const Shape& s)
// неправильное использование динамической
// информации о типе
{
if (ref_type_info(s)==static_type_info(Circle)) {
// для этой фигуры ничего не надо
}
else if (ref_type_info(s)==static_type_info(Triangle)) {
// вращение треугольника
}
else if (ref_type_info(s)==static_type_info(Square)) {
// вращение квадрата
}
// ...
}
Если для переключателя по типу поля мы используем динамическую
информацию о типе, то тем самым нарушаем в программе принцип
модульности и отрицаем сами цели объектно-ориентированного программирования.
К тому же это решение чревато ошибками: если в качестве
параметра функции будет передан объект производного от Circle класса,
то она сработает неверно (действительно, вращать круг (Circle)
нет смысла, но для объекта, представляющего производный класс, это
может потребоваться). Опыт показывает, что программистам, воспитанным
на таких языках как С или Паскаль, трудно избежать этой ловушки.
Стиль программирования этих языков требует меньше предусмотрительности,
а при создании библиотеки такой стиль можно просто считать
небрежностью.
Может возникнуть вопрос, почему в интерфейс с системой динамической
информации о типе включена условная операция приведения ptr_cast(), а не
операция is_base(), которая непосредственно определяется с помощью
операции has_base() из класса Type_info. Рассмотрим такой пример:
void f(dialog_box& db)
{
if (is_base(&db,dbox_w_str)) { // является ли db базовым
// для dbox_w-str?
dbox_w_str* dbws = (dbox_w_str*) &db;
// ...
}
// ...
}
Решение с помощью ptr_cast ($$13.5) более короткое, к тому же здесь
явная и безусловная операция приведения отделена от проверки в операторе
if, значит появляется возможность ошибки, неэффективности и даже
неверного результата. Неверный результат может возникнуть в тех
редких случаях, когда система динамической идентификации типа
распознает, что один тип является производным от другого, но
транслятору этот факт неизвестен, например:
class D;
class B;
void g(B* pb)
{
if (is_base(pb,D)) {
D* pb = (D*)pb;
// ...
}
// ...
}
Если транслятору пока неизвестно следующее описание класса D:
class D : public A, public B {
// ...
};
то возникает ошибка, т.к. правильное приведение указателя pb к D*
требует изменения значения указателя. Решение с операцией ptr_cast()
не сталкивается с этой трудностью, поскольку эта операция применима
только при условии, что в области видимости находятся описания
обеих ее параметров. Приведенный пример показывает, что операция
приведения для неописанных классов по сути своей ненадежна, но
запрещение ее существенно ухудшает совместимость с языком С.
13.6 Обширный интерфейс
Когда обсуждались абстрактные типы ($$13.3) и узловые классы ($$13.4),
было подчеркнуто, что все функции базового класса реализуются
в самом базовом или в производном классе. Но существует и другой
способ построения классов. Рассмотрим, например, списки, массивы,
ассоциативные массивы, деревья и т.д. Естественно желание для всех
этих типов, часто называемых контейнерами, создать обобщающий их
класс, который можно использовать в качестве интерфейса с любым
из перечисленных типов. Очевидно, что пользователь не должен
знать детали, касающиеся конкретного контейнера. Но задача
определения интерфейса для обобщенного контейнера нетривиальна.
Предположим, что такой контейнер будет определен как абстрактный
тип, тогда какие операции он должен предоставлять? Можно предоставить
только те операции, которые есть в каждом контейнере, т.е.
пересечение множеств операций, но такой интерфейс будет слишком
узким. На самом деле, во многих, имеющих смысл случаях такое
пересечение пусто. В качестве альтернативного решения можно
предоставить объединение всех множеств операций и предусмотреть
динамическую ошибку, когда в этом интерфейсе к объекту
применяется "несуществующая" операция. Объединение интерфейсов классов,
представляющих множество понятий, называется обширным интерфейсом.
Опишем "общий" контейнер объектов типа T:
class container {
public:
struct Bad_operation { // класс особых ситуаций
const char* p;
Bad_operation(const char* pp) : p(pp) { }
};
virtual void put(const T*)
{ throw Bad_operation("container::put"); }
virtual T* get()
{ throw Bad_operation("container::get"); }
virtual T*& operator[](int)
{ throw Bad_operation("container::[](int)"); }
virtual T*& operator[](const char*)
{ throw Bad_operation("container::[](char*)"); }
// ...
};
Все-таки существует мало реализаций, где удачно представлены как
индексирование, так и операции типа списочных, и, возможно, не стоит
совмещать их в одном классе.
Отметим такое различие: для гарантии проверки на этапе
трансляции в абстрактном типе используются чистые виртуальные
функции, а для обнаружения ошибок на этапе выполнения используются
функции обширного интерфейса, запускающие особые ситуации.
Можно следующим образом описать контейнер, реализованный
как простой список с односторонней связью:
class slist_container : public container, private slist {
public:
void put(const T*);
T* get();
T*& operator[](int)
{ throw Bad_operation("slist::[](int)"); }
T*& operator[](const* char)
{ throw Bad_operation("slist::[](char*)"); }
// ...
};
Чтобы упростить обработку динамических ошибок для списка
введены операции индексирования. Можно было не вводить эти
нереализованные для списка операции и ограничиться менее полной
информацией, которую предоставляют особые ситуации, запущенные
в классе container:
class vector_container : public container, private vector {
public:
T*& operator[](int);
T*& operator[](const char*);
// ...
};
Если быть осторожным, то все работает нормально:
void f()
{
slist_container sc;
vector_container vc;
// ...
}
void user(container& c1, container& c2)
{
T* p1 = c1.get();
T* p2 = c2[3];
// нельзя использовать c2.get() или c1[3]
// ...
}
Все же для избежания ошибок при выполнении программы часто приходится
использовать динамическую информацию о типе ($$13.5) или особые
ситуации ($$9). Приведем пример:
void user2(container& c1, container& c2)
/*
обнаружение ошибки просто, восстановление - трудная задача
*/
{
try {
T* p1 = c1.get();
T* p2 = c2[3];
// ...
}
catch(container::Bad_operation& bad) {
// Приехали!
// А что теперь делать?
}
}
или другой пример:
void user3(container& c1, container& c2)
/*
обнаружение ошибки непросто,
а восстановление по прежнему трудная задача
*/
{
slist* sl = ptr_cast(slist_container,&c1);
vector* v = ptr_cast(vector_container, &c2);
if (sl && v) {
T* p1 = c1.get();
T* p2 = c2[3];
// ...
}
else {
// Приехали!
// А что теперь делать?
}
}
Оба способа обнаружения ошибки, показанные на этих примерах,
приводят к программе с "раздутым" кодом и низкой скоростью
выполнения. Поэтому обычно просто игнорируют возможные ошибки
в надежде, что пользователь на них не натолкнется. Но задача от этого
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
