Дональд Бокс - Сущность технологии СОМ. Библиотека программиста

void *FastString::Dynam1c_Cast(const char *pszType)

{

if (strcmp(pszType, «IFastString») == 0) return static_cast(this);

else if (strcmp(pszType, «IPersistentObject») == 0) return static_cast(this);

else if (strcmp(pszType, «IExtensibleObject») == 0) return static_cast(this);

else return 0;

// request for unsupported interface

// запрос на неподдерживаемый интерфейс

}

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

Отметим, что после запроса на общий базовый интерфейс IExtensibleObject реализация статически преобразуется в IFastString. Это происходит потому, что интуитивная версия (intuitive version) оператора

return static_cast(this);

неоднозначна, так как и IFastString, и IPersistentObject порождены от IExtensibleObject. Если бы IExtensibleObject был виртуальным базовым классом как для IFastString, так и для IPersistentObject, то данное преобразование не было бы неоднозначным и оператор бы оттранслировался. Тем не менее, применение виртуальных базовых классов добавляет на этапе выполнения ненужную сложность в результирующий объект и к тому же вносит зависимость от транслятора. Дело в том, что виртуальные базовые классы являются всего лишь особенностями языка C++, которые имеют несколько специфических реализации.

Еще одна проблема поддержки нескольких интерфейсов из одного объекта становится яснее, если исследовать схему использования клиентом метода DynamicCast . Рассмотрим следующую клиентскую программу:

void f(void)

{

IFastString *pfs = 0;

IPersistentObject *ppo = 0;

pfs = CreateFastString(«Feed BOB»);

if (pfs) {

ppo = (IPersistentObject *) pfs->Dynami cCast(«IPersistentObject»);

if ( !ppo) pfs->Delete();

else { ppo->Save(«C:\\autoexec.bat»);

ppo->Delete(); }

}

}

Хотя вначале объект был связан через свой интерфейс IFastString , клиентский код вызывает метод Delete через интерфейс IPersistentObject . С использованием свойства C++ о множественном наследовании это вполне допустимо, так как все таблицы vtbl , порожденные классом IExtensibleObject , укажут на единственную реализацию метода Delete . Теперь, однако, пользователь должен хранить информацию о том, какие указатели связаны с какими объектами, и вызывать Delete только один раз на объект. В случае простого кода, приведенного выше, это не слишком тяжелое бремя. Для более сложных клиентских кодов управление этими связями становится делом весьма сложным и чреватым ошибками. Одним из способов упрощения задачи пользователя является возложение ответственности за управление жизненным циклом объекта на реализацию. Кроме того, разрешение клиенту явно удалять объект вскрывает еще одну деталь реализации: тот факт, что объект находится в динамически распределяемой памяти (в «куче», on the heap).

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

class IExtensibleObject

{

public:

virtual void *DynamicCast (const char* pszType) =0;

virtual void Delete(void) = 0;

};

на

class IExtensibleObject

{

public:

virtual void *DynamicCast(const char* pszType) = 0;

virtual void DuplicatePointer(void) = 0;

virtual void DestroyPointer(void) = 0;

};

Разместив эти методы, все пользователи IExtensibleObject должны теперь придерживаться следующих двух соображений:

1) Когда указатель интерфейса дублируется, требуется вызов DuplicatePointer .

2) Когда указатель интерфейса более не используется, следует вызвать DestroyPointer .

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

class FastString : public IFastString,

public IPersistentObject

{

int mcPtrs;

// count of outstanding ptrs

// счетчик невыполненных указателей

public:

// initialize pointer count to zero

// сбросить счетчик указателя в нуль

FastString(const char *psz) : mcPtrs(0) { }

void DuplicatePointer(void)

{

// note duplication of pointer

// отметить дублирование указателя

++mcPtrs;

}

void DestroyPointer(void)

{

// destroy object when last pointer destroyed

// уничтожить объект, когда уничтожен последний указатель

if (-mcPtrs == 0) delete this;

}

: : :

};

Этот совершенно стандартный код мог бы просто быть включен в базовый класс или в макрос С-препроцессора, чтобы его могли использовать все реализации.

Чтобы поддерживать эти методы, все программы, которые манипулируют или управляют указателями интерфейса, должны придерживаться двух простых правил DuplicatePointer/DestroyPointer . Для реализации FastString это означает модификацию двух функций. Функция CreateFastString берет начальный указатель, возвращаемый новым оператором C++, и копирует его в стек для возврата клиенту. Следовательно, необходим вызов DuplicatePointer :