Снова IUnknown
Снова IUnknown
IUnknown не имеет реализации по умолчанию, которая являлась бы частью интерфейса системного вызова СОМ. Заголовочные файлы SDK не содержат базовых классов, макросов или шаблонов, предусматривающих реализации QueryInterface, AddRef и Release, которые должны использоваться во всех программах на С или C++. Вместо этого Спецификация СОМ (Component Object Model Specification) предоставляет очень точные правила относительно допущений, которые клиенты и объекты могут делать относительно этих трех методов. Этот набор правил формирует протокол IUnknown и позволяет каждому разработчику объекта преобразовать три указанных метода IUnknown во все, что имеет смысл для его или ее объекта.
В главе 2 представлены фактические С++-реализации трех упомянутых методов, но СОМ никоим образом не обязывает объекты использовать их. Все, что требует СОМ, – это чтобы каждая реализация придерживалась базовых правил IUnknown. Как это достигается, не имеет ни малейшего отношения к СОМ. Это делает СОМ совершенно ненавязчивой, так как эта модель не требует, чтобы объект делал системные вызовы, наследовал системным реализациям, а все, что от него требуется, – это объявлять совместимые с СОМ указатели vptr. На самом деле, как будет показано далее в этой главе, можно выставлять наследующие IUnknown указатели vptr из классов, которые не наследуют ни одному интерфейсу СОМ.
Правила IUnknown в совокупности определяют, что значит быть объектом СОМ. Чтобы понять правила IUnknown, полезно начать с конкретного примера. Рассмотрим следующую иерархию интерфейсов:
import «unknwn.idl»;
[object, uuid(CD538340-A56D-11d0-8C2F-0080C73925BA)]
interface IVehicle : IUnknown {
HRESULT GetMaxSpeed([out, retval] long *pMax); }
[object, uuid(CD53834l-A56D-11d0-8C2F-0080C73925BA)]
interface ICar : IVehicle {
HRESULT Brake(void); }
[object, uuid(CD538342-A56D-11d0-8C2F-0080C73925BA)]
interface IPlane : IVehicle {
HRESULT TakeOff(void); }
[object, uuid(CD538343-A56D-11d0-8C2F-0080C73925BA)]
interface IBoat : IVehicle {
HRESULT Sink(void); }
СОМ использует стандартную технологию для визуального представления объектов. Эта технология находится в рамках принципа СОМ отделения интерфейса от реализации и не раскрывает никаких деталей реализации объекта, кроме списка выставляемых им интерфейсов. Эта технология также визуально усиливает многие из правил IUnknown. Рисунок 4.1 показывает стандартное представление класса CarBoatPlane, который реализует все только что определенные интерфейсы. Заметим, что единственный вывод, который можно сделать из этого рисунка, таков: если не произойдет катастрофического сбоя, объекты CarBoatPlane будут выставлять пять интерфейсов: IBoat, IPlane, ICar, IVehicle и IUnknown.
Первое правило IUnknown, подлежащее исследованию, – это требование, чтобы QueryInterface был симметричным, транзитивным и рефлексивным (Symmetric/Transitive/Reflexive). Эти требования определяют отношения между всеми интерфейсными указателями объекта и начинают определять понятие идентификации (identity) объектов СОМ. Подобно всем правилам IUnknown, эти требования должны исполняться всегда, за исключением катастрофических сбоев, теми, кто хочет считаться действительным объектом СОМ.
Более 800 000 книг и аудиокниг! 📚
Получи 2 месяца Литрес Подписки в подарок и наслаждайся неограниченным чтением
ПОЛУЧИТЬ ПОДАРОКЧитайте также
18.9.1 Снова о предосторожностях
18.9.1 Снова о предосторожностях В начале этой главы было уже сказано, что одновременное обращение к диску двух разных операционных систем может привести к неприятностям. Но об этом придется напомнить еще раз в связи с только что рассмотренной возможностью получения
Глава 6. Клиенты, которые покупают снова и снова
Глава 6. Клиенты, которые покупают снова и снова Начните вести клиентскую базу Большая часть прибыли интернет-магазинов строится на постоянных клиентах, которые совершают регулярные покупки. Однако часто покупатели не возвращаются лишь потому, что забыли про ваш
И снова про транзакции
И снова про транзакции Новичков иногда пугает "особенность" IBX закрывать все запросы при подтверждении или "откате" транзакции. Разместим на нашей форме две кнопки, как показано на рис. 2.10: Button 1 (свойство Caption равно Commit) и Button2 (Rollback). Рис 2.10. Кнопки управления
Интерфейс IUnknown
Интерфейс IUnknown СОМ-интерфейс IUnknown имеет то же назначение, что и интерфейс IExtensibleObject, определенный в предыдущей главе. Последняя версия IExtensibleObject, появившаяся в конце предыдущей главы, имеет вид:class IExtensibleObject{public:virtual void *Dynamic_Cast(const char* pszType) = 0;virtual void DuplicatePointer(void) = 0;virtual void
Управление ресурсами и IUnknown
Управление ресурсами и IUnknown Как было в случае с DuplicatePointer и DestroyPointer из предыдущей главы, методы AddRef и Release из IUnknown имеют очень простой протокол, которого должны придерживаться все, кто пользуется указателями этих интерфейсов. Эти правила освобождают клиента от
Приведение типов и IUnknown
Приведение типов и IUnknown В предыдущей главе обсуждалось, почему необходимо определять тип на этапе выполнения в динамически собранной системе. Язык C++ предусматривает разумный механизм для динамического определения типа с помощью оператора dynamic_cast. Хотя эта языковая
QueryInterface и IUnknown
QueryInterface и IUnknown Свойство рефлективности QueryInterface гарантирует, что любой интерфейсный указатель сможет удовлетворить запросы на IUnknown, поскольку все интерфейсные указатели неявно принадлежат к типу IUnknown. Спецификация СОМ имеет немного больше ограничений при описании
Снова выражения
Снова выражения Введение В последней главе мы изучили методы, используемые для синтаксического анализа и трансляции математических выражений в общей форме. Мы закончили созданием простого синтаксического анализатора, поддерживающего выражения произвольной
Снова о роли форматтера .NET
Снова о роли форматтера .NET Заключительным элементом головоломки удаленного взаимодействия .NET является форматтер. Типы TcpChannel и HttpChannel используют свои внутренние форматтеры, задачей которых является перевод объекта сообщения в термины соответствующего протокола. Как
И снова неограниченная универсальность
И снова неограниченная универсальность Конечно же, не все случаи универсальности ограничены. Форма - STACK [G] или ARRAY [G] - по-прежнему существует и называется неограниченной универсальностью. Пример DICTIONARY [G, H -> HASHABLE] показывает, что класс одновременно может иметь как
Ложь навсегда: почему нас обманывают снова и снова Василий Щепетнёв
Ложь навсегда: почему нас обманывают снова и снова Василий Щепетнёв Опубликовано 17 марта 2013 На днях попалась мне книга с примечательным названием: «Как узнать, что вас опять обманывают». Стояла она на полке магазина не вольно, а запечатанная в