конечно, имеет смысл учесть в программе отдельно вариант с slist. Допустив возможность определения истинного типа параметра, задающего множество, функцию my(set&) можно записать так:

void my(set& s)

if (ref type info(s) == static type info(slist set)) {

сравнение двух представлений типа s типа slist

slist& sl = (slist&)s;

for (T* p = sl.firstO; p; p = sl.nextO) { эффективный вариант в расчете на list

else {

for ( T* p = s.firstO; p; p = s.nextO) {

обычный вариант для произвольного множества

Как только стал известен конкретный тип slist, стали доступны определенные операции со списками, и даже стала возможна реализация основных операций подстановкой.

Приведенный вариант функции действует отлично, поскольку slist - это конкретный класс, и действительно имеет смысл отдельно разбирать вариант, когда параметр является slist set. Рассмотрим теперь такую ситуацию, когда желательно отдельно разбирать вариант как для класса, так и для всех его производных классов. Допустим, мы имеем класс dialog box из $$1 3.4 и хотим узнать, является ли он классом dbox w str. Поскольку может существовать много производных классов от dbox w str, простую проверку на совпадение с ним нельзя считать хорошим решением. Действительно, производные классы могут представлять самые разные варианты запроса строки. Например, один производный от dbox w str класс может предлагать пользователю варианты строк на выбор, другой может обеспечить поиск в каталоге и т.д. Значит, нужно проверять и на совпадение со всеми производными от dbox w str классами. Это так же типично для узловых классов, как проверка на вполне определенный тип типична для абстрактных классов, реализуемых конкретными типами.

void f(dialog box& db)

dbox w str* dbws = ptr cast(dbox w str, &db); if (dbws) { dbox w str

здесь можно использовать dbox w str::get string()

else {

обычныйdialog box

...

Здесь операция приведения ptr cast() свой второй параметр (указатель) приводит к своему первому параметру (типу) при условии, что указатель настроен на объект тип, которого совпадает с заданным (или является производным классом от заданного типа). Для проверки типа dialog box используется указатель, чтобы после приведения его можно было сравнить с нулем.

Возможно альтернативное решение с помощью ссылки на dialog box:

void g(dialog box& db)

try {

dbox w str& dbws = ref cast(dialog box,db); здесь можно использовать dbox w str::get string()

catch (Bad cast) {

Поскольку нет приемлемого представления нулевой ссылки, с которой можно сравнивать, используется особая ситуация, обозначающая ошибку приведения (т.е. случай, когда тип не есть dbox w str). Иногда лучше избегать сравнения с результатом приведения.

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

13.5.1 Информация о типе

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

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

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

typeid static type info(type) получить typeid для имени типа typeid ptr type info(pointer) получить typeid для указателя typeid ref type info(reference) получить typeid для ссылки pointer ptr cast(type,pointer) преобразование указателя reference ref cast(type,reference) преобразование ссылки

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

Большинство пользователей, которым вообще нужна динамическая идентификация типа, может ограничиться операциями приведения ptr cast() и ref cast(). Таким образом пользователь отстраняется от дальнейших сложностей, связанных с динамической идентификацией типа. Кроме того, ограниченное использование динамической информации о типе меньше всего чревато ошибками.

Если недостаточно знать, что операция приведения прошла успешно, а нужен истинный тип (например, объектно-ориентированный ввод-вывод), то можно использовать операции динамических запросов о типе: static type info(), ptr type info() и ref type info(). Эти операции возвращают объект класса typeid. Как было показано в примере с set и slist set, объекты класса typeid можно сравнивать. Для большинства задач этих сведений о классе typeid достаточно. Но для задач, которым нужна более полная информация о типе, в классе typeid есть функция get type info():

class typeid {

friend class Type info; private:

const Type info* id; public:

typeid(const Type info* p) : id(p) { } const Type info* get type info() const { return id; } int operator==(typeid i) const ;

Функция get type info() возвращает указатель на неменяющийся (const) объект класса Type info из typeid. Существенно, что объект не меняется: это должно гарантировать, что динамическая информация о типе отражает статические типы исходной программы. Плохо, если при выполнении программы некоторый тип может изменяться.

обычныйdialog box

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

13.5.2 Класс Type info

В классе Type info есть минимальный объем информации для реализации операции ptr cast(); его можно определить следующим образом:

class Type info {

const char* n; имя

const Type info** b; список базовых классов

public:

Type info(const char* name, const Type info* base[]); const char* name() const; Base iterator bases(int direct=0) const; int same(const Type info* p) const;

int has base(const Type info*, int direct=0) const; int can cast(const Type info* p) const; static const Type info info obj; virtual typeid get info() const; static typeid info();

Две последние функции должны быть определены в каждом производном от Type info классе.

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

const char* Type info::name() const return n;

int Type info::same(const Type info* p) const return this==p strcmp(n,p->n)==0;

int Type info::can cast(const Type info* p) const return same(p) p->has base(this);

Доступ к информации о базовых классах обеспечивается функциями bases() и has base(). Функция bases() возвращает итератор, который порождает указатели на базовые классы объектов Type info, а с помощью функции has base() можно определить является ли заданный класс базовым для другого класса. Эти функции имеют необязательный параметр direct, который показывает, следует ли рассматривать все базовые классы (direct=0), или только прямые базовые классы (direct=1). Наконец, как описано ниже, с помощью функций get info() и info() можно получить динамическую информацию о типе для самого класса Type info.

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