Эта маленькая программа выводит на экран сообщение, означающее все в порядке . vistt(Paragraph*)

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

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

Вывести корень иерархии из класса Basevisitable<YourReturnType>.

Добавить в каждый класс SomeClass, входящий в инспектируемую иерархию, макрос DEFlNE visiTABLE(). (Теперь иерархию можно инспектировать, однако никаких зависимостей от класса visitor больше нет!)

Вывести каждый конкретный инспектирующий класс из класса Basevisitor. Кроме того, для каждого класса X, подлежащего инспектированию, нужно вывести класс Somevisitor из класса visitor<x, YourReturnType>. Обеспечить замещение функции-члена Visit в каждом инспектируемом классе.

Диаграмма зависимостей, возникающая в результате этих действий, очень проста. Определение класса Somevisitor зависит по имени от каждого инспектируемого класса. Реализации функции-члена visit полностью зависят от классов, которыми они манипулируют.

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

В особых случаях функцию Accept лучше реализовывать непосредственно, а не с помошью макроса DEFINE VISITABLE(). Допустим, что мы определяем класс Section, производный от класса DocElement и содержащий несколько объектов класса Paragraph. Мы бы хотели инспектировать все объекты класса Paragraph, содержащиеся в объекте класса Section. В этом случае мы могли бы реализовать функцию Accept вручную.

class Section : public DocElement

функция Accept реализуется непосредственно,

а не через макрос DEFINE VISITABLE()

virtual ReturnType Accept(Basevisitor* v) {

for (каждый параграф в данном разделе) {

current paragraph->Accept(v);

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

Мы закончили разработку ядра реализации шаблона visitor, содержащего практически все, что необходимо для инспектирования. Продолжение следует.

10.5. Назад - к простому шаблону Visitor

Реализация обобщенного щаблона Acyclic visitor, определенная в предыдущем разделе, вполне удовлетворительно работает во многих ситуациях. Однако, если нужно создать быстродействующее приложение, динамическое приведение типов, выполняемое в функции Accept, может повергнуть вас в уныние, а измерения скорости работы ващей профаммы - прямо в состояние депрессии. Почему это происходит? Когда вы применяете оператор dynami c cast к некоторому объекту, система поддержки выполнения профамм должна произвести несколько действий. Код механизма RTTI должен определить, допустимо ли данное преобразование, и в случае положительного ответа вычислить указатель на объект результирующего типа.

Попробуем разобраться, как этого можно достичь при создании компилятора. Можно присвоить каждому типу, который фигурирует в профамме, уникальный целочисленный идентификатор. Этот идентификатор оказывается полезен и при обработке исключительных ситуаций. Тогда в виртуальную таблицу каждого класса компилятор записывает указатель на таблицу идентификаторов всех его подтипов. Вместе с ними компилятор должен хранить смещения подобъектов относительно базового объекта. Этой информации достаточно для правильного выполнения динамического приведения типов. Когда выполняется оператор dynamic cast<T2*>(pl), а парамеф р1 представляет собой указатель на объект типа т1 , система поддержки выполнения профамм про-смафивает таблицу типов в поисках типа, соответствующего типу Т2. Если соответствие с типом т2 обнаружено, система поддержки выполнения профамм выполнит необходимые арифметические операции с указателем и вернет результат. В противном случае будет возвращен нулевой указатель. Детали, в частности множественное наследование, еще больще усложняют и замедляют динамическое приведение типов.

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

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

Итак, оператор dynami c cast значительно снижает производительность профаммы, причем предсказать величину этого снижения невозможно. В некоторых случаях это оказывается совершенно неприемлемым. Следовательно, мы должны расширить нашу реализацию шаблона visitor, чтобы адаптировать циклический шаблон visitor, предложенный фуппой GoF. Это позволит повысить бысфодействие нашего приложения, так как в циклическом шаблоне visitor не используется динамическое приведение типов, хотя поддерживать его фуднее.

Работа шаблона visitor, предложенного группой GoF, уже описывалась в начале главы. Ниже перечисляются основные различия между обычным шаблоном visitor и шаблоном Acyclic visitor, реализованным в библиотеке Loki.

Класс Basevisitor больше не является фиктивным. В нем определяется одна чисто виртуальная функция-член visit для каждого инспектируемого типа (в предположении, что мы используем перефузку функций).

функция Acceptimpl должна измениться. В идеале макрос DEFINE VISITABLE() остается неизменным.

Все это сводится к следующему. У нас есть набор типов, подлежащих инспектированию: например, DocElement, Paragraph и RasterBitmap. Как выразить этот набор типов и манипулировать с ним? Естественно в этот момент на ум приходят списки типов, описанные в главе 3.

Списки типов - это именно то, что нам нужно. Мы хотим передавать список типов шаблонному классу CyclicVisitor в качестве шаблонного параметра, как бы говоря: Я хочу, чтобы данный класс CyclicVisitor мог инспектировать данные типы . Сделать это можно следующим элегантным способом.

неполное объявление, необходимое для списка типов class DocElement; class Paragraph; class RasterBitmap;

инспектирует классы DocElement, Paragraph и RasterBitmap

typedef CyclicVisitor

<

void, тип возвращаемого значения

TYPELIST 3(DocElement, Paragraph, RasterBitMap)

>

Myvisitor;

Класс CyclicVisitor зависит no имени от классов DocElement, Paragraph и RasterBitmap.

Посмотрим, какие дополнения нужно сделать в нашем коде. Используем процедуру, описанную в главе 9 при определении обобщенной реализации шаблона Abstract Factory.

Определение класса Private::visitorBinder<R> содержится в файле visitor.h template <typename R, class TList>

class CyclicVisitor : public GenmScatteredHierarchy<TList, Private::visitorBinder<R>::Result>

typedef R ReturnType; template <class visited> ReturnType visit(visited& host) {

visitor<visited>& subobj = *this; return subobj.visit(host);

Следует отметить, что класс CyclicVisitor использует класс visitor в качестве строительного блока. Аналогичный способ был продемонстрирован в главе 3, а похожий пример был рассмотрен в главе 9 По существу, класс CyclicVisitor наследует класс visitor<T> для каждого типа т, указанного в списке TList.

Если передать классу CyclicVisitor список типов, он завершит наследование от класса visitor, конкретизированного для каждого типа, указанного в данном списке, объявив таким образом по одной чисто виртуальной функции visit для каждого типа. Иными словами, с функциональной точки зрения он эквивалентен базовому классу visitor, как это предписывает щаблон visitor, предложенный группой GoF.