class object

{

public:

template <class T> virtual T * dynamic_cast(const type_info& t = typeid(T) )

};

(Аноним, 1995)

В главе 2 обсуждались основы интерфейсов СОМ вообще и интерфейс IUnknown в частности. Было дано понятие о том, что путем наследования дополнительным интерфейсам объекты могут выставлять более одного вида функциональных возможностей. Был также продемонстрирован механизм, с помощью которого клиенты могут опрашивать объекты, чтобы найти среди них доступные функциональные возможности. Этот механизм – QueryInterface (Интерфейс запросов) – был выделен как версия С++-оператора преобразования типа dynamic_cast, не зависящая от языка программирования и от компилятора.

В предыдущей главе было показано, что QueryInterface можно реализовать непосредственно, используя статические преобразования типа для того, чтобы ограничить область действия указателя this на объект типом интерфейса, который запрашивается клиентом. На физическом уровне этот способ означает просто преобразование идентификаторов интерфейса в объект с помощью соответствующего смещения, то есть способ, который применяется любым компилятором C++ при реализации dynamic_cast.

Хотя реализации QueryInterface из предыдущей главы являются вполне допустимыми для СОМ, правила 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, эти требования должны исполняться всегда, за исключением катастрофических сбоев, теми, кто хочет считаться действительным объектом СОМ.

Спецификация СОМ требует, чтобы, если запрос QueryInterface на интерфейс B удовлетворяется через интерфейсный указатель типа A, то запрос QueryInterface на интерфейс A того же самого объекта через результирующий интерфейсный указатель типа В всегда был успешным. Это значит, что если верно QI(A)->B, то также должно быть верным QI(QI(A)->B)->A

Из свойства, показанного на рис. 4.2, следует, что утверждение, заключенное в следующем коде, всегда должно быть истинным:

void AssertSymmetric(ICar *pCar) { if (pCar)

{

IPlane *pPlane = 0;

// request a second type of interface

// запрашиваем второй тип интерфейса

HRESULT hr = pCar->QueryInterface(IID_IPlane, (void**)&pPlane);

if (SUCCEEDED(hr)) { ICar *pCar2 = 0;

// request original type of interface

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

hr = pPlane->QueryInterface(IID_ICar, (void**)&pCar2);

// if the following assertion fails, pCar

// did not point to a valid СОМ object

// если следующее утверждение не будет правильным,

// то pCar не укажет на правильный СОМ-объект

assert(SUCCEEDED(hr));

pCar2->Release();

}

pPlane->Release();

}

}

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

Спецификация СОМ требует также, чтобы, если запрос QueryInterface на интерфейс В удовлетворяется через интерфейсный указатель типа A, а второй запрос QueryInterface на интерфейс C удовлетворяется через указатель типа В , то запрос QueryInterface на интерфейс C через исходный указатель типа A был бы также успешным. Это означает, что если верно QI(QI(A)->B)->C, то должно быть верным и QI(A)->C

Это условие иллюстрируется рис. 4.3 и означает, что утверждение, приведенное в нижеследующем коде, должно всегда быть верным:

void AssertTransitive(ICar *pCar)

{

if (pCar)

{

IPlane *pPlane = 0;

// request intermediate type of interface

// запрос промежуточного типа интерфейса

HRESULT hr = pCar->QueryInterface(IID_IPlane, (void**)&pPlane);

if (SUCCEEDED(hr))

{

IBoat *pBoat1 = 0;

// request terminal type of interface

// запрос конечного типа интерфейса

hr = pPlane->QueryInterface(IID_IBoat, (void**)&pBoat1);

if (SUCCEEDED(hr))

{

IBoat *pBoat2 = 0;

// request terminal type through the original pointer

// запрос конечного типа через исходный указатель

hr = pCar->QueryInterface(IID_IBoat, (void**)&pBoat2);

// if the following assertion fails, pCar

// did not point to a valid СОМ object

// если следующее утверждение неверно, то pCar

// не указывал на корректный СОМ-объект

assert(SUCCEEDED(hr));

pBoat2->Release();

}

pBoat1->Release();

}

pPlane->Release();

}

}

Из транзитивности QueryInterface следует, что все интерфейсы, которые выставляет объект, равноправны и не требуют, чтобы их вызывали в какой-то определенной последовательности. Если бы это было не так, то клиентам пришлось бы заботиться о том, какой указатель на объект использовать для различных запросов QueryInterface. Из транзитивности и симметричности QueryInterface следует, что любой интерфейсный указатель на объект выдаст тот же самый ответ «да/нет» на любой запрос QueryInterface. Единственная ситуация, не охватываемая транзитивностью и симметричностью, это повторные запросы одного и того же интерфейса. Эта ситуация требует, чтобы QueryInterface был и рефлективным.

Спецификация СОМ требует, чтобы запрос QueryInterface через интерфейсный указатель всегда достигал цели, если запрошенный тип соответствует типу указателя, с помощью которого произведен запрос. Это означает, что QI(A)->A всегда должен быть верным.

Это требование проиллюстрировано рис. 4.4 и в следующем фрагменте кода:

void AssertReflexive(ICar *pCar)

{

if (pCar)

{

ICar *pCar2 = 0;

// request same type of interface

// запрос интерфейса того же типа

HRESULT hr = pCar->QueryInterface(IID_ICar, (void**)&pCar2);

// if the following assertion fails, pCar

// did not point to a valid СОМ object

// если следующее утверждение неверно, то pCar

// не указывает на корректный объект СОМ

assert(SUCCEEDED(hr));

pCar2->Release();

}

}

Из этого кода следует, что все реализации ICar должны быть способны удовлетворить дополнительные запросы QueryInterface для ICar через интерфейсный указатель ICar. Если бы это не соблюдалось, то было бы невозможно передавать жестко типизированные интерфейсы через параметры базового типа без невосполнимой потери исходного типа:

extern void GetCar(ICar **ppcar);

extern void UseVehicle(IVehicle *pv);

ICar *pCar;

GetCar(&pCar);

UseVehicle(pCar);

// ICar-ness is syntactically lost

// ICar-ность синтаксически потеряна

void UseVehicle(IVehicle *pv)

{

ICar *pCar = 0;

// try to regain syntactic ICar-ness

// пытаемся восстановить синтаксическую ICar-ность

HRESULT hr = pv->QueryInterface(IID_ICar, (void**)&pCar);

}

Поскольку указатель, использованный в функции UseVehicle , имеет то же самое значение, что и указатель ICar , переданный вызывающим объектом, то выглядело бы неестественным (counterintuitive), если бы этот тип не мог быть восстановлен внутри функции.

Из того, что QueryInterface является симметричным, рефлексивным и транзитивным, следует, что любой интерфейсный указатель на объект должен выдавать тот же самый ответ «да/нет» на данный запрос QueryInterface. Это позволяет клиентам рассматривать иерархию типов объекта как простой граф, все вершины которого непосредственно соединены друг с другом (и с самими собой) с помощью открытых (explicit) ребер. На рис. 4.5 изображен такой граф. Отметим, что в любую вершину графа можно попасть из любой другой вершины, пройдя вдоль только одного ребра.

Один из выводов, который можно сделать из трех требований QueryInterfасе , состоит в том, что множество интерфейсов, поддерживаемых объектом, не может изменяться во времени. Спецификация СОМ четко требует, чтобы этот вывод был верен для всех объектов. Из этого требования следует, что иерархия типов объекта является статичной, несмотря на тот факт, что для определения множества поддерживаемых типов данных клиенты должны опрашивать объекты динамически. Если объект отвечает «да» на запрос интерфейса типа А, то он должен отвечать «да», начиная с этой точки. Если объект отвечает «нет» на запрос интерфейса типа А , то он должен отвечать «нет», начиная с этой точки. Фраза «начиная с этой точки» (from that point on) буквально переводится как «до тех пор, пока есть хотя бы один внешний указатель интерфейса на объект». Обычно это соответствует жизненному циклу базового объекта C++, но язык Спецификации СОМ обладает достаточной свободой, чтобы предоставить разработчикам определенную гибкость (например, иерархия типов глобальной переменной может изменяться, когда все указатели освобождены).

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

void AssertStaticType(IUnknown *pUnk, REFIID riid)

{

IUnknown *pUnk1 = 0,

*pUnk2 = 0;

HRESULT hr1 = pUnk->QueryInterface(riid, (void**)&pUnk1);

HRESULT hr2 = pUnk->QueryInterface(riid, (void**)&pUnk2);

// both requests for the same interface should

// yield the same yes/no answer

// оба запроса того же самого интерфейса

// должны получить тот же самый ответ да/нет

assert(SUCCEEDED(hr1) == SUCCEEDED(hr2));

if (SUCCEEDED(hr1)) pUnk1->Release();

if (SUCCEEDED(hr2)) pUnk2->Release();

}

Это требование означает, что в СОМ запрещены следующие программные технологии:

Использование временной информации при решении вопроса о том, удовлетворять или нет запрос QueryInterface (например, выдавать интерфейс IMorning (утро) только до 12:00).

Использование переменной информации о состоянии при решении вопроса о том, удовлетворять или нет запрос QueryInterface (например, выдавать интерфейс INotBusy (не занят), только если количество внешних интерфейсных указателей меньше десяти).

Использование маркера доступа (security token) вызывающего объекта для решения, удовлетворять или нет запрос QueryInterface . Как будет объяснено в главе 6, на самом деле это не обеспечивает никакой реальной безопасности из-за протокола передачи (wire protocol ), используемого СОМ.

Использование успешного захвата динамических ресурсов для решения вопроса о том, удовлетворять или нет запрос QueryInterface (например, выдавать интерфейс IHaveTonsOfMemory (у меня тонны памяти) только при успешном выполнении malloc(4096*4096)).

Эта последняя методика может быть до некоторой степени смягчена, если разработчик объекта желает поупражняться с выражением спецификации СОМ «barring catastrophic failure» (за исключением катастрофического сбоя).

Эти ограничения не означают, что два объекта одного и того же класса реализации не могут давать различные ответы «да/нет» при запросе одного и того же интерфейса. Например, класс может реализовать показанные ранее интерфейсы ICar, IBoat и IPlane , но может разрешить только одному интерфейсу быть использованным в каком-то определенном объекте. Эти ограничения также не означают, что объект не может использовать постоянную или временную информацию для решения вопроса о том, дать ли исходное «да» или «нет» для данного интерфейса. В примере для класса, который разрешает только один из трех интерфейсов, следующая идиома была бы вполне допустимой:

class СВР : public ICar, public IPlane, public IBoat

{

enum TYPE { CAR, BOAT, PLANE, NONE };

TYPE m_type;

CBP(void) : m_type(NONE) { }

STDMETHODIMP QueryInterface(REFIID riid, void **ppv)

{

if (md == IID_ICar)

{

// 1st QI Initializes type of object

// первая QI инициализирует тип объекта

if (m_type == NONE) m_type = CAR;

// only satisfy request if this object is a car

// удовлетворяем запрос, только если данный объект

// является car (автомобилем)

if (m_type == CAR) *ppv = static_cast<ICar*>(this);

else return (*ppv = 0), E_NOINTERFACE;

}

else if (md == IID_IBoat)

{

// similar treatment for IBoat and IPlane

// IBoat и IPlane обрабатываются сходным образом

}

};

Из требования, чтобы множество поддерживаемых интерфейсов было статичным, следует простой вывод, что разработчикам объектов не разрешается создавать конструкции, состоящие из одного объекта, который дает два различных ответа «да/нет» на запрос определенного интерфейса. Одна из причин того, что иерархия типов объекта должна оставаться неизменной на всем протяжении своего жизненного цикла, состоит в том, что СОМ не гарантирует отправления всех клиентских запросов QueryInterface такому объекту в случае, когда к нему имеется удаленный доступ. Неизменность иерархии типов позволяет «заместителям» на стороне клиента (client-side proxies) кэшировать результаты QueryInterface во избежание чрезмерных обменов клиент-объект. Такая оптимизация очень важна для эффективности СОМ, но она разрушает конструкции, использующие QueryInterface для передачи динамической семантической информации вызывающему объекту.

Предыдущий раздел был посвящен запросам QueryInterface, которые представляют собой ответы типа «да/нет» вызывающим объектам. QueryInterface действительно возвращает S_OK (да) или E_NOINTERFACE (нет). Впрочем, когда QueryInterface возвращает S_OK, то он также возвращает объекту интерфейсный указатель. Для СОМ значение этого указателя чрезвычайно важно, так как оно позволяет клиентам определить, действительно ли на один и тот же объект указывают два интерфейсных указателя.

Свойство рефлективности QueryInterface гарантирует, что любой интерфейсный указатель сможет удовлетворить запросы на IUnknown, поскольку все интерфейсные указатели неявно принадлежат к типу IUnknown. Спецификация СОМ имеет немного больше ограничений при описании результатов запросов QueryInterface именно на IUnknown. Объект не только должен отвечать «да» на запрос, он должен также возвращать в ответ на каждый запрос в точности одно и то же значение указателя. Это означает, что в следующем коде оба утверждения всегда должны быть верны:

void AssertSameObject(IUnknown *pUnk)

{

IUnknown *pUnk1 = 0,

*pUnk2 = 0;

HRESULT hr1 = pUnk->QueryInterface(IID_IUnknown, (void **)&pUnk1);

HRESULT hr2 = pUnk->QueryInterface(IID_IUnknown, (void **)&pUnk2);

// QueryInterface(IUnknown) must always succeed

// QueryInterface(IUnknown) должно всегда быть успешным

assert(SUCCEEDED(hr1) && SUCCEEDED(hr2));

// two requests for IUnknown must always yield the

// same pointer values

// два запроса на IUnknown должны всегда выдавать

// те же самые значения указателя

assert(pUnk1 == pUnk2);

pUnk1->Release();

pUnk2->Release();

}

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

bool IsSameObject(IUnknown *pUnk1, IUnknown *pUnk2)

{ assert(pUnk1 && pUnk2);

bool bResult = true;

if (pUnk1 != pUnk2)

{

HRESULT hr1, hr2; IUnknown *p1 = 0, *p2 = 0;

hr1 = pUnk1->QueryInterface(IID_IUnknown, (void **)&p1);

assert(SUCCEEDED(hr1));

hr2 = pUnk2->QueryInterface(IID_IUnknown, (void **)&p2);

assert(SUCCEEDED(hr2));

// compare the two pointer values, as these

// represent the identity of the object

// сравниваем значения двух указателей,

// так как они идентифицируют объект

bResult = (р1 == р2); p1->Release();

p2->Release();

}

return bResult;

}

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

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

class CarBoatPlane : public ICar, public IBoat, public IPlane

{

public:

// IUnknown methods – методы IUnknown

STDMETHODIMP QueryInterface(REFIID, void**);

STDMETHODIMP_(ULONG) AddRef(void);

STDMETHODIMP_(ULONG) Release(void);

// IVehicle methods – методы IVehicle

STDMETHODIMP GetMaxSpeed(long *pMax);

// ICar methods – методы

ICar STDMETHODIMP Brake(void);

// IBoat methods – методы

IBoat STDMETHODIMP Sink(void);

// IPlahe methods – методы

IPlane STDMETHODIMP TakeOff(void); };

Ниже приведена стандартная реализация QueryInterface в CarBoatPlane:

STDMETHODIMP QueryInterface(REFIID riid, void **ppv)

{

if (riid == IID_IUnknown) *ppv = static_cast<ICar*>(this);

else if (riid == IID_IVehicle) *ppv = static_cast<ICar*>(this);

else if (riid == IID_ICar) *ppv = static_cast<ICar*>(this);

else if (riid == IID_IBoat) *ppv = static_cast<IBoat*>(this);

else if (riid == IID_IPlane) *ppv = static_cast<IPlane*>(this);

else return (*ppv = 0), E_NOINTERFACE;

((IUnknown*)*ppv)->AddRef();

return S_OK;

}

Для того чтобы быть объектом СОМ, реализация CarBoatPlane QueryInterface должна полностью придерживаться правил IUnknown , приведенных в данной главе.

Класс CarBoatPlane выставляет интерфейсы только типа ICarIPlane, IBoat, IVehicle и IUnknown . Каждая таблица vtbl CarBoatPlane будет ссылаться на единственную реализацию QueryInterface, показанную выше. К каждому поддерживаемому интерфейсу можно обращаться через эту реализацию QueryInterface, так что невозможно найти два несимметричных интерфейса, то есть не существует двух интерфейсов A и B, для которых неверно следующее:

If QI(A)->B Then QI(QI(A)->B)->A

Если следовать той же логике, то поскольку все пять интерфейсов принадлежат к одной и той же реализации QueryInterface, не существует трех интерфейсов А, В и С , для которых неверно следующее:

If QI(QI(A)->B)->C Then QI(A)->C

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

QI(A)->A

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

Реализация также корректно выполняет правило СОМ об идентификации, возвращая только одно значение указателя при запросе IUnknown:

if (riid == IID_IUnknown) *ppv = static_cast<ICar*>(this);

Если бы реализация QueryInterface возвращала различные указатели vptr для каждого запроса:

if (riid == IID_IUnknown)

{

int n = rand() % 3;

if (n == 0) *ppv = static_cast<ICar*>(this);

else if (n == 1) *ppv = static_cast<IBoat*>(this);

else if (n == 2) *ppv = static_cast<IPlane*>(this);

}

то реализация была бы корректной только в терминах чисто С++-отношений типа (то есть все три интерфейса были бы совместимы по типу с запрошенным типом IUnknown). Эта реализация, однако, не является допустимой с точки зрения СОМ, поскольку правило идентификации для QueryInterface было нарушено.

Множественное наследование является очень эффективной и простой технологией для реализации интерфейсов СОМ в классе C++. Это требует написания очень короткого явного кода, так как большая часть работы компилятора и компоновшика заключается в построении соответствующих СОМ указателей vptr и таблиц vtbl. Если имя метода появляется более чем в одном базовом классе с идентичными типами параметров, то компилятор и компоновщик заполняют каждый элемент vtbl таким образом, чтобы он указывал на одну реализацию метода в классе. Этот режим применяется к таким методам, как QueryInterface, AddRef и Release, так как все интерфейсы СОМ начинаются с этих методов, и все же разработчику класса требуется написать каждый метод только один раз (и это хорошо). Этот же режим применяется и к методам любых интерфейсов, где происходит повтор имени и сигнатуры. Здесь есть одна возможная ловушка множественного наследования.

Иерархия транспортных интерфейсов из этой главы содержит конфликт имен. В интерфейсе ICar (автомобиль) имеется метод, названный GetMaxSpeed (развить максимальную скорость). В интерфейсах IBoat (лодка) и IPlane (самолет) также имеются методы, именуемые GetMaxSpeed с идентичной сигнатурой. Это означает, что при использовании множественного наследования разработчик класса пишет метод GetMaxSpeed один раз, а компилятор и компоновщик инициализируют таблицы vtbl , совместимые с ICar, IBoat и IPlane так, чтобы они указывали только на эту реализацию.

Возможно, это вполне разумное поведение для большого числа реализации. Но что если объекту нужно было вернуть другую максимальную скорость, зависящую от интерфейса, на который был сделан запрос? Поскольку имя и сигнатуры одинаковы, то необходимо принимать неординарные меры для разрешения множественных реализации конфликтного метода. Один из возможных способов состоит в создании промежуточного класса C++, производного от интерфейса и реализующего конфликтный метод путем создания чисто виртуального вызова неконфликтного имени:

struct IXCar : public ICar {

// add new non-clashing method as pure virtual

// добавляем новый неконфликтный метод как чисто виртуальный

virtual HRESULT STDMETHODCALLTYPE GetMaxCarSpeed(long *pval) = 0;

// implement clashing method by upcalling

// non-clashing implementation in derived class

// реализуем конфликтный метод путем вызова

// неконфликтной реализации в производном классе

STDMETHODIMP GetMaxSpeed(long *pval)

{ return GetMaxCarSpeed(pval); }

};

Допуская, что интерфейсы IBoat и IPlane подвергнуты подобной операции, можно реализовывать различные версии GetMaxSpeed простым наследованием от расширенных версий интерфейсов и переопределением неконфликтных версий каждого метода GetMaxSpeed:

class CarBoatPlane: public IXCar, public IXBoat, public IXPlane

{

public:

// Unknown methods – методы IUnknown

STDMETHODIMP QueryInterface(REFIID, void**);

STDMETHODIMP_(ULONG) AddRef(void);

STDMETHODIMP_(ULONG) Release(void);

// IVehicle methods – методы IVehicle

// do not override GetMaxSpeed!

// не подменяем GetMaxSpeed!

// ICar methods – методы ICar

STDMETHODIMP Brake(void);

// IBoat methods – методы IBoat

STDMETHODIMP Sink(void);

// IXPlane methods – методы IXPlane

STDMETHODIMP TakeOff(void);

// upcalled from IXCar::GetMaxSpeed

// вызвано из IXCar::GetMaxSpeed

STDMETHODIMP GetMaxCarSpeed(long *pval);

// upcalled from IXBoat::GetMaxSpeed

// вызвано из IXBoat::GetMaxSpeed

STDMETHODIMP GetMaxBoatSpeed(long *pval);

// called from IXPlane::GetMaxSpeed

// вызвано из IXPlane::GetMaxSpeed

STDMETHODIMP GetMaxPlaneSpeed(long *pval);

}

Рисунок 4.6 иллюстрирует представление этого класса и форматы таблиц vtbl. Отметим, что конфликтный метод GetMaxSpeed не реализован в этом классе. Поскольку каждый из базовых классов CarBoatPlane подменяет этот чисто виртуальный метод, то CarBoatPlane не нуждается в создании своей собственной реализации. Действительно, если бы в CarBoatPlane нужно было подменить GetMaxSpeed, то одна его реализация этого метода подменила бы версии, вызываемые из каждого базового класса, аннулировав результат использования IXCar, IXBoat и IXPlane. В силу этой проблемы данная технология годится только в тех ситуациях, когда можно быть уверенным, что класс реализации (или любые возможные производные классы) никогда не станет подменять конфликтный метод.

Другой способ обеспечения множественных реализации конфликтных методов состоит в том, чтобы усилить правила IUnknown . Спецификация СОМ не требует, чтобы объект был реализован как класс C++. Хотя существует весьма естественное соответствие между объектами СОМ и классами C++, базирующимися на множественном наследовании, это всего лишь одна из возможных технологий реализации. Для создания объекта СОМ может быть использована любая программная технология, производящая таблицы vtbl в нужном формате и удовлетворяющая правилам СОМ для QueryInterface. Один стандартный метод разрешения конфликтов имен состоит в реализации интерфейсов с конфликтующими именами как отдельных классов C++ и последующей компоновке целевого класса C++ из экземпляров этих отдельных классов. Для гарантии того, что каждый из этих составных элементов данных появится во внешнем мире как единый объект СОМ, часто назначается одна главная реализация QueryInterface, которой каждый составной элемент данных будет передавать функции. Следующий код демонстрирует эту технологию:

class CarPlane

{

LONG m_cRef;

CarPlane(void) : m_cRef(0) {}

public:

// Main IUnknown methods

// Главные методы IUnknown

STDMETHODIMP QueryInterface(REFIID, void**);

STDMETHODIMP_(ULONG) AddRef(void);

STDMETHODIMP_(ULONG) Release(void);

private:

// define nested class that implements ICar

// определяем вложенный класс, реализующий

ICar struct XCar : public ICar

{

// get back pointer to main object

// получаем обратный указатель на главный объект

inline CarPlane* This();

STDMETHODIMP QueryInterface(REFIID, void**);

STDMETHODIMP_(ULONG) AddRef(void);

STDMETHODIMP_(ULONG) Release(void);

STDMETHODIMP GetMaxSpeed(long *pval);

STDMETHODIMP Brake(void);

};

// define nested class that implements IPlane

// определяем вложенный класс, реализующий IPlane

struct XPlane : public IPlane {

// Get back pointer to main object

// получаем обратный указатель на главный объект

inline CarPlane* This();

STDMETHODIMP QueryInterface(REFIID, void**);

STDMETHODIMP_(ULONG) AddRef(void);

STDMETHODIMP_(ULONG) Release(void);

STDMETHODIMP GetMaxSpeed(long *pval);

STDMETHODIMP TakeOff(void);

};

// declare instances of nested classes

// объявляем экземпляры вложенных классов

XCar m_xCar;

XPlane m_xPlane;

};

Использование вложенных классов не является обязательным, но оно подчеркивает, что эти подчиненные классы не имеют смысла вне контекста класса CarPlane. Рисунок 4.7 показывает двоичное размещение этого класса и размещения соответствующих vtbl .

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

STDMETHODIMP CarPlane::XCar::GetMaxSpeed(long *pn) {

// set *pn to max speed for cars

// устанавливаем *pn для максимальной скорости автомобилей

}

STDMETHODIMP CarPlane::XPlane::GetMaxSpeed(long *pn) {

// set *pn to max speed for planes

// устанавливаем *pn для максимальной скорости самолетов

}

Тот факт, что две реализации GetMaxSpeed встречаются в различных определениях вложенных классов, позволяет определить метод дважды и к тому же гарантирует то, что таблицы vtbl, соответствующие ICar и IPlane, будут иметь различные элементы для GetMaxSpeed.

Необходимо также отметить, что хотя класс CarPlane, находящийся на верхнем уровне, реализует методы IUnknown, он не наследует никакому производному от IUnknown классу. Вместо этого объекты CarPlane имеют элементы данных, которые наследуют интерфейсам СОМ. Это значит, что вместо того, чтобы использовать static_cast для вхождения в объект и нахождения определенного указателя vptr, реализация QueryInterface в CarPlane должна возвратить указатель на тот элемент данных, который реализует запрашиваемый интерфейс:

STDMETHODIMP CarPlane::QueryInterface(REFIID riid, void **ppv)

{

if (riid == IID_IUnknown) *ppv = static_cast<IUnknown*>(&m_xCar);

else if (riid == IID_IVehicle) *ppv = static_cast<IVehicle*> (&m_xCar);

else if (riid == IID_ICar) *ppv = static_cast<ICar*>(&m_xCar);

else if (riid == IID_IPlane) *ppv = static_cast<IPlane*>(&m_xPlane);

else return (*ppv = 0), E_NOINTERFACE;

((IUnknown*)(*ppv))->AddRef();

return S_OK;

}

Для обеспечения идентификации объекта каждый из элементов данных CarPlane должен или воспроизвести этот код в своей собственной реализации QueryInterface, или просто передать управление главной функции QueryInterface в CarPlane. Чтобы осуществить это, необходим механизм перехода к главному объекту со стороны функции-члена составного элемента данных. Определение класса CarPlane::XCar содержит встроенную подпрограмму, которая использует фиксированные смещения для вычисления указателя this главного объекта от указателя this составного элемента данных.

inline CarPlane CarPlane::XCar::This(void)

{

return (CarPlane*)((char*)this

// ptr to composite – указатель на композит – offsetof (CarPlane, m_xCar)); }

inline CarPlane CarPlane::XPlane::This(void)

{

return (CarPlane*)((char*)this

// ptr to composite – указатель на композит

– offsetof(CarPlane, m_xPlane));

}

Такая технология вычисления обратного указателя (back-pointer) компактна и чрезвычайно эффективна, так как не требует явных элементов данных для нахождения главного объекта внутри реализации метода элемента данных. При наличии таких алгоритмов вычисления обратного указателя реализация композитного QueryInterface становится тривиальной:

STDMETHODIMP CarPlane::XCar::QueryInterface(REFIID r, void**p)

{

return This()->QueryInterface(r, p);

}

STDMETHODIMP CarPlane::XPlane::QueryInterface(REFIID r, void**p)

{

return This()->QueryInterface(r, p);

}

Такая же передача this потребуется для AddRef и Release для получения обобщенного представления о времени жизни объекта в случае составных (композитных) элементов данных.

Технология, основанная на использовании композиции для реализации интерфейсов, требует значительно больше кода, чем при простом множественном наследовании. Кроме того, качество генерированного кода, вероятно, не лучше (а возможно, и хуже), чем в случае множественного наследования. Из того факта, что классу CarPlane не понадобилось наследовать ни одному интерфейсу СОМ, следует, что композиция является разумной технологией для внесения СОМ в старые библиотеки классов. Например, MFC (Microsoft Foundation Classes – библиотека базовых классов Microsoft) использует эту технологию. Причиной применения композиции при реализации новых классов является получение отдельных реализации метода, определенного одинаково более чем в одном интерфейсе. К счастью, стандартные интерфейсы, определяемые СОМ, очень редко создают такие конфликты, а те немногие, которые создают, почти всегда преобразуются в семантически эквивалентные функции. Для разрешения коллизий, подобных тем, что произошли в сценарии с GetMaxSpeed , композиция, вероятно, и не требуется, так как в первом приближении для преобразования двойников в уникальные объекты достаточно использования промежуточных классов. Эта методика проста, эффективна и фактически не требует дополнительного кода. Основная причина использования композиции в новом коде заключается в том, что нужно обеспечить подсчет ссылок в каждом интерфейсе.

Иногда желательно разместить ресурсы в объекте на базе уже использующихся интерфейсов. В то же время из использования множественного наследования для реализации интерфейсов СОМ следует, что в каждой таблице vtbl будет использована только одна реализация AddRef и Release. Хотя можно выявить первый запрос на заданный интерфейс и разместить ресурсы по требованию:

STDMETHODIMP QueryInterface(REFIID riid, void **ppv)

{

if (riid == IID_IBoat)

{

// allocate resource the first time through

// размещаем ресурсы при первом проходе

if (m_pTonsOfMemory == 0) m_pTonsOfMemory = new char[4096 * 4096];

*ppv = static_cast<IBoat*>(this);

}

else if

…

}

не существует способа определить момент, когда больше нет внешних указателей интерфейса IBoat, так как вызов Release, который клиент делает через интерфейс IBoat, неотличим от вызова Release, сделанного через любой другой интерфейс объекта. В обычной ситуации именно это и нужно, но в данном случае вызовы AddRef и Release через интерфейсы IBoat необходимо рассматривать иначе. Если бы интерфейс IBoat был реализован с использованием композиции, то он имел бы свои собственные уникальные реализации AddRef и Release, в которых он мог бы поддерживать свой собственный счетчик ссылок, отличный от счетчика главного объекта:

class CarBoatPlane : public ICar, public IPlane

{

LONG m_cRef;

char *m_pTonsOfMemory;

CarBoatPlane (void) : m_cRef(0),

m_pTonsOfMemory (0) {}

public:

// IUnknown methods – методы IUnknown

STDMETHODIMP QueryInterface(REFIID, void**);

STDMETHODIMP_(ULONG) AddRef(void);

STDMETHODIMP_(ULONG) Release(void);

// IVehicle methods – методы IVehicle

STDMETHODIMP GetMaxSpeed(long *pMax);

// ICar methods – методы ICar

STDMETHODIMP Brake(void);

// IPlane methods – методы IPlane

STDMETHODIMP TakeOff(void);

// define nested class that implements IBoat

// определяем вложенный класс, реализующий IBoat

struct XBoat : public IBoat {

// get back pointer to main object

// получаем обратный указатель на главный объект

inline CarBoatPlane* This();

LONG m_cBoatRef;

// per-interface ref count

// счетчик ссылок на каждый интерфейс

XBoat(void) : m_cBoatRef(0) {}

STDMETHODIMP QueryInterface(REFIID, void**);

STDMETHODIMP_(ULONG) AddRef(void);

STDMETHODIMP_(ULONG) Release(void);

STDMETHODIMP GetMaxSpeed(long *pval);

STDMETHODIMP Sink(void);

};

XBoat m_xBoat; };

Реализация AddRef и Release из IBoat могут теперь следить за числом ссылок типа IBoat и высвободить ресурсы, когда они больше не нужны:

STDMETHODIMP_(ULONG) CarBoatPlane::XBoat::AddRef()

{

ULONG res = InterlockedIncrement(&m_cBoatRef);

if (res == 1)

{

// first AddRef – первый AddRef

// allocate resource and forward AddRef to object

// размещаем ресурсы и пересылаем AddRef на объект

This()->m_pTonsOfMemory = new char[4096*4096];

This()->AddRef(); }

return res; }

STDMETHODIMP_(ULONG) CarBoatPlane::XBoat::Release()

{

ULONG res = InterlockedDecrement(&m_cBoatRef);

if (res == 0) {

// last Release – последний Release

// free resource and forward Release to object

// освобождаем ресурсы и пересылаем Release на объект

delete [] This()->m_pTonsOfMemory;

This()->Release();

} return res; }

Чтобы эта методика работала, все пользующиеся интерфейсными указателями должны придерживаться требований спецификации СОМ: функция Release должна вызываться через указатель, посредством которого вызывается соответствующая функция AddRef. Поэтому правильной концовкой QueryInterface будет следующая:

((IUnknown*)(*ppv))->AddRef();

// use exact ptr

// используем точный указатель return S_OK;

вместо такого:

AddRef();

// just call this->AddRef

// только вызов

this->AddRef return S_OK;

Первый вариант гарантирует, что если клиент пишет следующий правильный код

IBoat *pBoat = 0;

HRESULT hr = pUnk->QueryInterface(IID_IBoat, (void**)&pBoat);

if (SUCCEEDED(hr))

{ hr = pBoat->Sink(); pBoat->Release(); }

то для AddRef и для Release обязательно будет использовано одно и то же значение указателя.

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

class CarBoatPlane : public ICar, public IPlane

{ public: struct XBoat : public IBoat

{

// composite QI/AddRef/Release/This()

// композит из QI/AddRef/Release/This()

IMPLEMENT_COMPOSITE_UNKNOWN(CarBoatPlane, XBoat, m_xBoat) STDMETHODIMP GetMaxSpeed(long *pval);

STDMETHODIMP Sink(void);

};

XBoat m_xBoat;

// IVehicle methods

// методы IVehicle

STDMETHODIMP GetMaxSpeed(long *pMax);

// ICar methods

// методы ICar

STDMETHODIMP Brake(void);

// IPlane methods

// методы IPlane

STDMETHODIMP TakeOff(void);

// standard heap-based QI/AddRef/Release

// стандартные расположенные в «куче» QI/AddRef/Release

IMPLEMENT_UNKNOWN(CarBoatPlane)

BEGIN_INTERFACE_TABLE(CarBoatPlane)

IMPLEMENTS_INTERFACE_AS(IVehicle, ICar)

IMPLEMENTS_INTERFACE(ICar)

IMPLEMENTS_INTERFACE(IPlane)

// macro that calculates offset of data member

// макрос, вычисляющий смещение элемента данных

IMPLEMENTS_INTERFACE_WITH_COMPOSITE(IBoat, XBoat, m_xBoat)

END_INTERFACE_TABLE() };

В приведенном выше определении класса опущены только определения методов объекта вне QueryInterfасе, AddRef и Release. Два новых макроса, использованных в определении класса, определяются следующим образом:

// inttable.h

// (book-specific header file)

// (заголовочный файл, специфический для данной книги)

#define COMPOSITE_OFFSET(ClassName, BaseName, \

MemberType, MemberName) \

(DWORD(static_cast<BaseName*>(\

reinterpret_cast<MemberType*>(0x10000000 + \

offsetof(ClassName, MemberName)))) – 0х10000000)

#define IMPLEMENTS_INTERFACE_WITH_COMPOSITE(Req,\

MemberType, MemberName) \

{ &IID_##Req,ENTRY_IS_OFFSET, COMPOSITE_OFFSET(_IT,\

Req, MemberType, MemberName) },

// impunk.h

// (book-specific header file)

// (заголовочный файл, специфический для данной книги)

#define IMPLEMENT_COMPOSITE_UNKNOWN(OuterClassName,\

InnerClassName, DataMemberName) \

OuterClassName *This() \

{ return (OuterClassName*)((char*)this – \

offsetof(OuterClassName, DataMemberName)); }\

STDMETHODIMP QueryInterface(REFIID riid, void **ppv)\

{ return This()->QueryInterface(riid, ppv); }\

STDMETHODIMP_(ULONG) AddRef(void) \

{ return This()->AddRef(); }\

STDMETHODIMP_(ULONG) Release(void) \

{ return This()->Release(); }

Эти макросы препроцессора просто дублируют фактические реализации QueryInterface, AddRef и Release , использованные в композиции.

Если для реализации интерфейса в классе C++ используется множественное наследование или композиция, то в каждом объекте этого класса будут содержаться служебные данные (overhead) указателя vptr размером в четыре байта на каждый поддерживаемый интерфейс (принимая, что sizeof (void*) == 4). Если число интерфейсов, экспортируемых объектом, невелико, то эти служебные данные не играют важной роли, особенно в свете преимуществ, предоставляемых программной моделью СОМ. Если, однако, число поддерживаемых интерфейсов велико, то размер служебных данных vptr может вырасти до такой степени, что часть объекта, не связанная с СОМ, будет казаться маленькой по сравнению с ними. При использовании каждого из этих интерфейсов все время без служебных данных не обойтись. Если же, однако, эти интерфейсы не будут использоваться никогда или использоваться в течение короткого времени, то можно воспользоваться лазейкой в Спецификации СОМ и оптимизировать vptr некоторых неиспользуемых объектов.

Вспомним правило, гласящее, что все запросы QueryInterface на объект относительно IUnknown должны возвращать точно такое же значение указателя. Именно так в СОМ обеспечивается идентификация объектов. В то же время Спецификация СОМ определенно разрешает возвращать другие значения указателей в ответ на запросы QueryInterface относительно любых других типов интерфейсов, кроме IUnknown. Это означает, что для нечасто используемых интерфейсов объект может динамически выделять память для vptr по требованию, не заботясь о возврате того же самого динамически выделенного блока памяти каждый раз, когда запрашивается какой-либо интерфейс. Эта технология временного (transient) размещения композитов впервые была описана в «белой книге» Microsoft Поваренная книга для программистов СОМ (Microsoft white paper The СОМ Programmer's Cookbook), написанной Криспином Госвеллом (Crispin Goswell) (http://www.microsoft.com/oledev). В этой «белой книге» такие временные интерфейсы называются отделяемыми (tearoff).

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

1) главный объект динамически размещает отделяемый интерфейс вместо того, чтобы иметь элемент данных экземпляра, и

2) отделяемый композит должен содержать явный обратный указатель на главный объект, так как технология фиксированного смещения, используемая в композиции, здесь не работает, поскольку отделяемый интерфейс изолирован от основного объекта. Следующий класс реализует IBoat как отделяемый интерфейс:

class CarBoat : public ICar

{

LONG m_cRef;

CarBoat (void): m_cRef(0) {}

public:

// IUnknown methods

// методы IUnknown

STDMETHODIMP QueryInterface(REFIID, void**);

STDMETHODIMP_(ULONG) AddRef(void);

STDMETHODIMP_(ULONG) Release(void);

// IVehicle methods

// методы IVehicle

STDMETHODIMP GetMaxSpeed(long *pMax);

// ICar methods

// методы ICar

STDMETHODIMP Brake(void);

// define nested class that implements IBoat

// определяем вложенный класс, реализующий IBoat

struct XBoat : public IBoat

{

LONG m_cBoatRef;

// back pointer to main object is explicit member

// обратный указатель на главный объект – явный член

CarBoat *m_pThis;

inline CarBoat* This()

{

return m_pThis;

}

XBoat(CarBoat *pThis);

~XBoat(void);

STDMETHODIMP QueryInterface(REFIID, void**);

STDMETHODIMP_(ULONG) AddRef(void);

STDMETHODIMP_(ULONG) Release(void);

STDMETHODIMP GetMaxSpeed(long *pval);

STDMETHODIMP Sink(void);

};

// note: no data member of type Xboat

// заметим: нет элементов данных типа Xboat

};

Для QueryInterface главного объекта необходимо динамически разместить новый отделяемый интерфейс – каждый раз, когда запрашивается IBoat:

STDMETHODIMP CarBoat::QueryInterface(REFIID riid, void **ppv)

{

if (riid == IID_IBoat)

*ppv = static_cast<IBoat*>(new XBoat(this));

else if (riid == IID_IUnknown)

*ppv = static_cast<IUnknown*>(this);

: 

:

:

Каждый раз при получении запроса на интерфейс IBoat размещается новый отделяемый интерфейс. Согласно стандартной практике QueryInterface вызова AddRef посредством результирующего указателя: ((IUnknown*)*ppv)->AddRef();

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

CarBoat::XBoat::XBoat(CarBoat *pThis) : m_cBoatRef(0), m_pThis(pThis)

{

m_pThis->AddRef();

}

CarBoat::XBoat::~XBoat(void)

{

m_pThis->Release();

}

Как и в случае с композицией, методу QueryInterface отделяемого интерфейса требуется идентифицировать объект, делегируя освобождение функции главного объекта. Однако отделяемый интерфейс может выявлять запросы на тот интерфейс (интерфейсы), который он сам реализует, и просто возвращать указатель, обработанный AddRef, себе самому:

STDMETHODIMP CarBoat::XBoat::QueryInterface(REFIID riid, void**ppv)

{

if (riid != IID_IBoat) return This()->QueryInterface(riid, ppv);

*ppv = static_cast<IBoat*>(this);

reinterpret_cast<IUnknown*>(*ppv)->AddRef();

return S_OK;

}

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

STDMETHODIMP_(ULONG) CarBoat::XBoat::AddRef (void)

{

return InterlockedIncrement(&m_cRef);

}

STDMETHODIMP_(ULONG) CarBoat::XBoat::Release(void)

{

ULONG res = InterlockedDecrement(&m_cBoatRef);

if (res == 0) delete this;

// dtor releases main object

// деструктор освобождает главный объект

return res;

}

Как и в случае с композицией, метод This() можно использовать в любых методах отделяемого интерфейса, которым требуется получить статус главного объекта. Разница состоит в том, что отделяемым интерфейсам требуется явный обратный указатель, в то время как нормальные композиты могут использовать фиксированные смещения, выделяя по четыре байта на композит.

На первый взгляд, отделяемые интерфейсы кажутся лучшей из всех возможностей. Когда интерфейс не используется, то на его служебные данные отводится нуль байт объекта. Когда же интерфейс используется, объект косвенно тратит 4 байта на служебные данные отделяемого интерфейса. Подобное впечатление базируется на нескольких обманчивых предположениях. Во-первых, затраты на работающий отделяемый интерфейс составляют отнюдь не только 4 байта памяти для его vptr. Отделяемому интерфейсу требуются также обратный указатель и счетчик ссылок[1]. Во-вторых, несмотря на возможность использования специального распределителя памяти (custom memory allocator ), отделяемому интерфейсу потребуется по крайней мере 4 дополнительных байта на выравнивание и/или заполнение заголовков динамически выделенной памяти, используемых С-библиотекой для реализации malloc/operator new . Это означает, что объект действительно экономит 4 байта, когда интерфейс не используется. Но когда интерфейс используется, отделяемый интерфейс тратит как минимум 12 байт, если подключен специальный распределитель памяти, и 16 байт, если, по умолчанию, подключен оператор new. Если интерфейс запрашивается редко, то такая оптимизация имеет смысл, особенно если клиент освобождает этот интерфейс вскоре после получения. Если же клиент хранит отделяемый интерфейс в течение всего времени жизни объекта, то преимущества отделяемого интерфейса теряются.

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

Узнав обо всех подводных камнях отделяемых интерфейсов, задаешь себе логичный вопрос: "В каких же случаях отделяемые интерфейсы являются подходящими?" Не существует безусловного ответа; в то же время отделяемые интерфейсы очень хороши для поддержки большого числа взаимно исключающих интерфейсов. Рассмотрим случай, в котором в дополнение к трем транспортным интерфейсам, показанным ранее, имеются интерфейсы ITruck (грузовик), IMonsterТruck (грузовик-монстр), IMotorcycle (мотоцикл), IBicycle (велосипед), IUnicycle (уницикл), ISkateboard (скейтборд) и IHelicopter (вертолет), причем все они наследуют IVehicle. Если бы производящий транспортный класс хотел поддерживать любой из этих интерфейсов, но только по одному из них для каждого заданного экземпляра, то для осуществления этого отделяемые интерфейсы были бы прекрасным способом при условии, что главный объект кэшировал бы указатель на первый отделяемый интерфейс. Определение класса главного объекта выглядело бы примерно так:

class GenericVehicle : public IUnknown

{

LONG m_cRef;

IVehicle *m_pTearOff;

// cached ptr to tearoff

// кэшированный указатель на отделяемый интерфейс

GenericVehicle(void) : m_cRef(0), m_pTearOff(0) {}

// IUnknown methods

// методы IUnknown

STDMETHODIMP QueryInterface(REFIID, void **);

STDMETHODIMP_(ULONG) AddRef(void);

STDMETHODIMP_(ULONG) Release (void);

// define tearoff classes

// определяем классы отделяемых интерфейсов

class XTruck : public ITruck { … };

class XMonsterTruck : public IMonsterTruck { … };

class XBicycle : public IBicycle { … };

:

:

:

};

В этом классе в случае, когда не используется ни один из интерфейсов, объект платит за пустой кэшированный указатель только четырьмя дополнительными байтами. Когда приходит запрос QueryInterfасе на один из десяти транспортных интерфейсов, то память выделена для нового отделяемого интерфейса один раз и кэширована для более позднего использования:

STDMETHODIMP GenericVehicle::QueryInterface(REFIID riid ,void **ppv)

{ if (riid == IID_IUnknown) *ppv = static_cast<IUnknown*>(this);

else if (riid == IID_ITruck) { if (m_pTearOff == 0)

// no tearoff yet, make one

// отделяемого интерфейса еще нет, создаем один

m_pTearOff = new XTruck(this);

if (m_pTearOff)

// tearoff exists, let tearoff QI

// отделяемый интерфейс существует, пусть это QI

return m_pTearOff->QueryInterface(riid, ppv);

else

// memory allocation failure

// ошибка выделения памяти

return (*ppv = 0), E_NOINTERFACE;

}

else if (riid == IID_IMonsterTruck)

{

if (in_pTearOff == 0)

// no tearoff yet, make one

// отделяемого интерфейса еще нет, создаем один

m_pTearOff = new XMonsterTruck(this);

if (m_pTearOff)

// tearoff exists, let tearoff QI

// отделяемый интерфейс существует, пусть это QI

return m_pTearOff->QueryInterface(riid, ppv);

else

// memory allocation failure

// ошибка выделения памяти

return (*ppv = 0), E_NOINTERFACE;

}

else …

:

:

:

}

На основе показанной здесь реализации QueryInterface на каждый объект будет приходиться по большей части по одному отделяемому интерфейсу. Это значит, что в случае отсутствия запросов на транспортные интерфейсы объект будет тратить в сумме 12 байт (vptr IUnknown + счетчик ссылок + кэшированный указатель на отделяемый интерфейс). Если транспортный интерфейс запрошен, то объект будет тратить в сумме от 24 до 28 байт (исходные 12 байт + наследующий Vehicle vptr + счетчик ссылок + обратный указатель на главный объект + (необязательно) служебная запись malloc (memory allocation – выделение памяти)).

Если бы в данном случае отделяемые интерфейсы не использовались, то определение класса выглядело бы примерно так:

class GenericVehicle : public ITruck, public IHelicopter, public IBoat, public ICar, public IMonsterTruck, public IBicycle, public IMotorcycle, public ICar, public IPlane, public ISkateboard { LONG m_cRef;

// IUnknown methods – методы IUnknown

:

:

:

};

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

Композиция и отделяемые интерфейсы – это две технологии на уровне исходного кода, предназначенные для реализации объектов СОМ на C++. Обе эти технологии требуют, чтобы разработчик объекта имел определения для каждого класса композита или отделяемого интерфейса в исходном коде C++, для возможности обработать подобъект, прежде чем возвратить его посредством QueryInterface. Для ряда ситуаций это очень разумно. В некоторых случаях, однако, было бы удобнее упаковать многократно используемую реализацию одного или большего числа интерфейсов в двоичный компонент, который мог бы обрабатываться через границы DLL, не нуждаясь в исходном коде подкомпонента. Это позволило бы более широкой аудитории повторно использовать подкомпонент, избегая слишком тесной связи с ним, как в случае повторного использования на уровне исходного кода (этот случай описан в главе 1). Однако если компонент повторного использования представляет собой двоичный композит или отделяемый интерфейс, то он должен участвовать в общей идентификации объекта.

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

class Car : public ICar

{

LONG m_cRef; Car(void) : m_cRef(0) {} STDMETHODIMP QueryInterface(REFIID, void **);

STDMETHODIMP_(ULONG) AddRef(void); STDMETHODIMP_(ULONG) Release(void);

STDMETHODIMP GetMaxSpeed(long *pn);

STDMETHODIMP Brake(void); };

STDMETHODIMP Car::QueryInterface(REFIID riid, void **ppv)

{

if (riid == IID_IUnknown) *ppv = static_cast<IUnknown*>(this);

else if (riid == IID_IVehicle) *ppv = static_cast<IVehicle*>(this);

else if (riid == IID_ICar) *ppv = static_cast<ICar*>(this);

else return (*ppv = 0), E_NOINTERFACE;

((IUnknown*)*ppv)->AddRef();

return S_OK;

}

// car class object's IClassFactory::CreateInstance

// интерфейс IClassFactory::CreateInstance

// объекта класса car

STDMETHODIMP CarClass::CreateInstance(IUnknown *pUnkOuter, REFIID riid, void **ppv)

{

Car *pCar = new Car;

if (*pCar) return (*ppv = 0), E_OUTOFMEMORY;

pCar->AddRef();

HRESULT hr = pCar->QueryInterface(riid, ppv);

pCar->Release(); return hr;

}

Этот класс просто использует фактические реализации QueryInterface, AddRef и Release.

Рассмотрим второй класс C++, который пытается использовать реализацию Car как двоичный композит:

class CarBoat : public IBoat

{

LONG m_cRef;

Unknown *m_pUnkCar;

CarBoat(void);

virtual ~CarBoat(void);

STDMETHODIMP QueryInterface(REFIID, void **);

STDMETHODIMP_(ULONG) AddRef(void);

STDMETHODIMP_(ULONG) Release(void);

STDMETHODIMP GetMaxSpeed(long *pn);

STDMETHODIMP Sink(void);

};

Для эмуляции композиции разработчику пришлось бы создать подобъект Car, а деструктору – освободить указатель на подобъект:

CarBoat::CarBoat (void) : m_cRef(0)

{

HRESULT hr = CoCreateInstance(CLSID_Car, 0, CLSCTX_ALL, IID_IUnknown, (void**)&m_pUnkCar);

assert(SUCCEEDED(hr));

}

CarBoat::~CarBoat(void)

{

if (m_pUnkCar) m_pUnkCar->Release();

}

Интересная проблема возникает в реализации QueryInterface:

STDMETHODIMP CarBoat::QueryInterface(REFIID riid, void **ppv)

{

if (riid == IID_IUnknown) *ppv = static_cast<IUnknown*>(this);

else if (riid == IID_IVehicle) *ppv = static_cast<IVehicle*>(this);

else if (riid == IID_IBoat) *ppv = static_cast<IBoat*>(this);

else if (riid == IID_ICar)

// forward request…

// переадресовываем запрос…

return m_pUnkCar->QueryInterface(riid, ppv);

else return (*ppv = 0), E_NOINTERFACE; ((IUnknown*)*ppv)->AddRef();

return S_OK;

}

Поскольку объект Car не имеет понятия о том, что он является частью идентификационной единицы (identity) другого объекта, то он будет причиной неуспеха любых запросов QueryInterface для IBoat. Это означает, что

QI(IBoat)->ICar

пройдет успешно, а запрос

QI(QI(IBoat)->ICar)->IBoat

потерпит неудачу, так как полученная QueryInterface будет несимметричной. Вдобавок запросы QueryInterface о IUnknown через интерфейсные указатели ICar и IBoat вернут различные значения, а это означает, что будет идентифицировано два различных объекта. Из подобных нарушений протокола IUnknown следует, что объекты CarBoat попросту не являются действительными объектами СОМ.

Идея составления объекта из двоичных композитов звучит красиво. Действительно, Спецификация СОМ четко и подробно указывает, как реализовать эту идею в стандартной и предсказуемой манере. Технология выставления клиенту двоичного подкомпонента непосредственно через QueryInterface называется СОМ-агрегированием. СОМ-агрегирование является лишь набором правил, определяющих отношения между внешним объектом (агрегирующим) и внутренним (агрегируемым). СОМ-агрегирование – это просто набор правил IUnknown, позволяющих более чем одному двоичному компоненту фигурировать в качестве идентификационной единицы (identity) СОМ.

Агрегирование СОМ несомненно является главной движущей силой для повторного использования в СОМ. Намного проще приписывать объекту значения и использовать его методы в реализации методов других объектов. Только в редких случаях кто-то захочет выставлять интерфейсы другого объекта непосредственно клиенту как часть той же самой идентификационной единицы. Рассмотрим следующий сценарий:

class Handlebar : public IHandlebar { … };

class Wheel : public IWheel {};

class Bicycle : public IBicycle

{

IHandlebar * m_pHandlebar;

IWheel *m_pFrontWheel;

IWheel *m_pBackWheel;

}

Было бы опрометчиво для класса Вicycle объявлять интерфейсы IHandlebar (велосипедный руль) или IWheel (колесо) в собственном методе QueryInterface. QueryInterface зарезервирован для выражения отношений «является» (is-a), а велосипед (bicycle) очевидно не является колесом (wheel) или рулем (handlebar). Если разработчик Bicycle хотел бы обеспечить прямой доступ к этим сторонам объекта, то интерфейс IBicycle должен был бы иметь для этой цели аксессоры определенных свойств:

[object, uuid(753A8A60-A7FF-11d0-8C30-0080C73925BA)] interface IBicycle : IVehicle

{

HRESULT GetHandlebar([out,retval] IHandlebar **pph);

HRESULT GetWheels([out] IWheel **ppwFront, [out] IWheel **ppwBack);

}

Реализация Bicycle могла бы тогда просто возвращать указатели на свои подобъекты:

STDMETHODIMP Bicycle::GetHandlebar(IHandlebar **pph)

{

if (*pph = m_pHandlebar) (*pph)->AddRef();

return S_OK;

}

STDMETHODIMP Bicycle::GetWheels(IWheel **ppwFront, IWheel **ppwBack)

{

if (*ppwFront = m_pFrontWheel) (*ppwFront)->AddRef();

if (*ppwBack = m_pBackWheel) (*ppwBack)->AddRef();

return S_OK;

}

При использовании данной технологии клиент по-прежнему получает прямой доступ к подобъектам. Однако поскольку указатели получены через явные методы, а не через QueryInterface, то между различными компонентами не существует никаких идентификационных отношений.

Несмотря на этот пример, все же остаются сценарии, где желательно обеспечить реализацию интерфейса, которая могла бы быть внедрена в идентификационную единицу другого объекта. Чтобы осуществить это, в СОМ-агрегировании требуется, чтобы внутренний объект (агрегируемый) уведомлялся во время его создания, что он создается как часть идентификационной единицы другого объекта. Это означает, что создающая функция (creation function), обычно используемая для создания объекта, требует один дополнительный параметр: указатель IUnknown на идентификационную единицу, которой агрегирующий объект должен передать функции в ее методы QueryInterface, AddRef и Release. Покажем определение метода CreateInstance интерфейса IClassFactory:

HRESULT CreateInstance([in] Unknown *pUnkOuter, [in] REFIID riid, [out, iid_is(riid)] void **ppv);

Этот метод (и соответствующие API-функции CoCreateInstanceEx и CoCreateInstance) перегружен с целью поддержки создания автономных (stand-alone ) объектов и агрегатов. Если вызывающий объект передает нулевой указатель и качестве первого параметра CreateInstance (pUnkOuter ), то результирующий объект будет автономной идентификационной единицей самого себя. Если же вызывающий объект передает в качестве первого параметра ненулевой указатель, то результирующий объект будет агрегатом с идентификационной единицей, ссылка на которую содержится в pUnkOuter. В случае агрегации агрегат должен переадресовывать все запросы QueryInterface, AddRef и Release непосредственно и безусловно на pUnkOuter. Это необходимо для обеспечения идентификации объекта.

Имея прототип функции, приведенный выше, класс CarBoat после небольшой модификации будет удовлетворять правилам агрегации:

CarBoat::CarBoat(void) : m_cRef(0)

{

// need to pass identity of self to Create routine

// to notify car object it 1s an aggregate

// нужно передать свою идентификацию подпрограмме

// Create для уведомления объекта car, что он – агрегат

HRESULT hr = CoCreateInstance(CLSID_Car, this, CLSCTX_ALL, IID_IUnknown, (void**)&m_pUnkCar);

assert(SUCCEEDED(hr));

}

Реализация CarBoat QueryInterface просто переадресовывает запрос ICar внутреннему агрегату:

STDMETHODIMP CarBoat::QueryInterface(REFIID riid, void **ppv)

{

if (riid == IID_IUnknown) *ppv = static_cast<IUnknown*>(this);

else if (riid == IID_ICar)

// forward request…

// переадресовываем запрос…

return m_pUnkCar->QueryInterface(riid, ppv);

else if (riid == IID_IBoat)

:

:

:

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

В предыдущем сценарии метод CreateInstance класса Car возвращает внешнему объекту указатель интерфейса, наследующего IUnknown. Если бы этот интерфейсный указатель должен был просто делегировать вызовы функций интерфейсу IUnknown внешнего объекта, то невозможно было бы: 1) уведомить агрегат, что он больше не нужен; 2) запросить интерфейсные указатели при выделении их клиентам главного объекта. На деле результатом приведенной выше реализации QueryInterface будет бесконечный цикл, поскольку внешний объект делегирует функции внутреннему, который делегирует их обратно внешнему.

Для решения этой проблемы необходимо сделать так, чтобы начальный интерфейсный указатель, который возвращается внешнему объекту, не делегировал вызовы реализации IUnknown внешнего объекта. Это означает, что объекты, поддерживающие СОМ– агрегирование, должны иметь две реализации IUnknown. Делегирующая, то есть передающая функции, реализация переадресовывает все запросы QueryInterface, AddRef и Release внешней реализации. Это и есть реализация по умолчанию, на которую ссылаются таблицы vtbl всех объектов, и это именно та версия, которую видят внешние клиенты. Объект должен также иметь неделегирующую реализацию IUnknown, которая выставляется только агрегирующему внешнему объекту.

Имеется несколько возможностей обеспечить две различные реализации IUnknown от одного объекта. Самый прямой путь[1] – это использование композиции и элемента данных для реализации неделегирующих методов IUnknown. Ниже показана реализация Car, поддающаяся агрегации:

class Car : public ICar

{

LONG m_cRef;

IUnknown *m_pUnk0uter;

public: Car(IUnknown *pUnk0uter);

// non-delegating IUnknown methods

// неделегирующие методы

IUnknown STDMETHODIMP InternalQueryInterface(REFIID, void **);

STDMETHODIMP (ULONG) InternalAddRef(void);

STDMETHODIMP_(ULONG) InternalRelease(void);

// delegating IUnknown methods

// делегирующие методы IUnknown

STDMETHODIMP QueryInterface(REFIID, void **);

STDMETHODIMP_(ULONG) AddRef(void);

STDMETHODIMP_(ULONG) Release(void);

STDMETHODIMP GetMaxSpeed(*long *pn);

STDMETHODIMP Brake(void);

// composite to map distinguished IUnknown vptr to

// non-delegating InternalXXX routines in main object

// композит для преобразования определенного vptr IUnknown

// в неделегирующие подпрограммы InternalXXX в главном

// объекте

class XNDUnknown : public IUnknown

{ Car* This()

{

return (Car*)((BYTE*)this – offsetof(Car, m_innerUnknown));

}

STDMETHODIMP QueryInterface(REFIID r, void**p)

{

return This()->InternalQueryInterface(r,p);

}

STDMETHODIMP_(ULONG) AddRef(void)

{

return This()->InternalAddRef();

}

STDMETHODIMP_(ULONG) Release(void)

{

return This()->InternalRelease();

}

};

XNDUnknown m_innerUnknown;

// composite instance

// экземпляр композита };

Двоичное размещение этого объекта показано на рис. 4.8. Методы делегирования класса чрезвычайно просты:

STDMETHODIMP Car::QueryInterface(REFIID riid, void **ppv) { return m_pUnkOuter->QueryInterface(riid, ppv); }

STDMETHODIMP_(ULONG) Car::AddRef(void) { return m_pUnkOuter->AddRef(); }

STDMETHODIMP_(ULONG) Car::Release (void) { return m_pUnkOuter->Release(); }

Эти подпрограммы являются версиями, которые будут заполнять таблицы vtbl всех интерфейсов объекта, так что какой бы интерфейс клиент ни получил, методы IUnknown всегда передают функции основной идентификационной единице объекта.

Для того чтобы объект можно было использовать в обоих сценариях – агрегирования и автономном – разработчик объекта должен установить свой элемент данных m_pUnkOuter так, чтобы в случае автономного режима он указывал на собственный неделегирующий IUnknown:

Car::Car(IUnknown *pUnkOuter)

{

if (pUnkOuter)

// delegate to pUnkOuter

// делегируем в pUnkOuter

m_pUnkOuter = pUnkOuter;

else // delegate to non-delegating self

// делегируем неделегирующему себе m_pUnkOuter = &m_innerUnknown;

}

Разработчик обеспечивает то, что в обоих случаях m_pUnkOuter указывает на нужную для данного объекта реализацию QueryInterface, AddRef и Release.

Обычные неделегирующие реализации QueryInterface, AddRef и Release являются вполне правильными и предсказуемыми:

STDMETHODIMP Car::InternalQueryInterface(REFIID riid, void **ppv)

{

if (riid == IID_IUnknown) *ppv = static_cast<IUnknown*>(&m_innerUnknown);

else if (riid = IID_IVehicle) *ppv = static_cast<IVehicle*>(this);

else if (riid == IID_ICar) *ppv = static_cast<ICar*>(this);

else return (*ppv = 0), E_NOINTERFACE;

((IUnknown*)*ppv)->AddRef();

return S_OK;

}

STDMETHODIMP_(ULONG) Car::InternalAddRef(void)

{

return InterlockedIncrement(&m_cRef);

}

STDMETHODIMP_(ULONG) Car::InternalRelease(void)

{

ULONG res = InterlockedDecrement(&m_cRef);

if (res == 0) delete this;

return res;

}

Единственной отличительной особенностью этих трех методов (кроме их имен) является то, что InternalQueryInterface при запросе IUnknown возвращает указатель на неделегирующую Unknown. Это просто требование Спецификации СОМ, которого следует придерживаться.

И наконец, подпрограмму создания Car требуется модифицировать для поддержки агрегирования:

STDMETHODIMP CarClass::CreateInstance(IUnknown *punk0uter, REFIID riid, void **ppv)

{

// verify that aggregator only requests IUnknown as

// initial interface

// проверяем, что агрегатор только запрашивает IUnknown как

// начальный интерфейс

if (pUnkOuter != 0 && riid != IID_IUnknown)

return (*ppv = 0), E_INVALIDARG;

// create new object/aggregate

// создаем новый объект или агрегат Car

*р = new Car(pUnkOuter);

if (!p) return (*ppv = 0), E_OUTOFMEMORY;

// return resultant pointer

// возвращаем результирующий указатель

p->InternalAddRef();

HRESULT hr = p->InternalQueryInterface(riid, ppv);

p->InternalRelease();

return hr;

}

Отметим, что здесь используются неделегирующие версии QueryInterface, AddRef и Release. Если создается автономная идентификационная единица, то это, конечно, допустимо. Если же создается агрегат, то необходимо убедиться, что AddRef обработал внутренний, а не внешний объект. Отметим также, что внешний объект в качестве начального интерфейса должен запросить IUnknown. Все это регламентировано Спецификацией СОМ. Если бы внешний объект мог запрашивать произвольный начальный интерфейс, то внутреннему объекту пришлось бы хранить два дублирующих набора указателей vptr: один набор делегировал бы свои реализации QueryInterface, AddRef и Release, а другой – нет. При допущении в качестве начального интерфейса одного IUnknown разработчик объекта может выделить только один vptr, который будет действовать как неделегирующий IUnknown.

При программировании с СОМ-агрегированием может возникнуть опасность, связанная со счетчиком ссылок. Отметим, что разработчик внутреннего объекта дублирует указатель на управляющий внешний объект, но не вызывает AddRef. Вызов AddRef в данной ситуации запрещен, поскольку если оба объекта будут обрабатывать друг друга посредством AddRef, то получится бесконечный цикл. Правила подсчета ссылок при агрегировании требуют, чтобы внешний объект хранил указатель на внутренний неделегирующий IUnknown объекта (это указатель, возвращенный подпрограммой создания объекта) после подсчета ссылок на этот указатель. Внутренний объект хранит указатель на IUnknown управляющего внешнего объекта с неподсчитанными ссылками. Формально эти соотношения зафиксированы в специальной формулировке правил СОМ для счетчиков ссылок. Вообще-то методику использования указателей без подсчета ссылок применять нельзя, поскольку ее невозможно реализовать в случае удаленного доступа к объектам. Более эффективный способ избежать зацикливания счетчика ссылок состоит в том, чтобы ввести промежуточные идентификационные единицы (identities) объектов, счетчики ссылок которых не повлияют на время жизни никакого объекта.

Еще одна проблема при программировании агрегирования может возникнуть, когда необходимо связать между собой внутренний и внешний объекты. Для того чтобы организовать связь внутреннего объекта с внешним, нужно вызвать QueryInterface посредством управляющего IUnknown. Однако этот запрос QueryInterface вызовет AddRef через результирующий указатель, который имеет обыкновение без спросу обрабатывать внешний объект с помощью AddRef. Если бы внутренний объект хранил этот указатель в качестве элемента данных, то возник бы цикл, поскольку внутренний объект уже неявно обработал внешний объект с помощью AddRef. Это означает, что внутренний объект должен избрать одну из двух стратегий. Внутренний объект может получать и освобождать указатель по потребности, храня его ровно столько времени, сколько это необходимо:

STDMETHODIMP Inner::MethodX(void)

{

ITruck *pTruck = 0;

// outer object will be AddRefed after this call…

// после этого вызова внешний объект будет обработан

// с помощью AddRef…

HRESULT hr = m_pUnkOuter->QueryInterface(IID_ITruck, (void**)&pTruck);

if (SUCCEEDED(hr))

{

pTruck->ShiftGears();

pTruck->HaulDirt();

// release reference to outer object

// освобождаем ссылку на внешний объект pTruck->Release();

}

}

Второй способ заключается в том, чтобы получить указатель один раз во время инициализации и освободить соответствующий внешний объект немедленно после получения.

HRESULT Inner::Initialize(void)

{

// outer object will be AddRefed after this call…

// после этого вызова внешний объект будет обработан

// с помощью AddRef…

HRESULT hr = m_pUnkOuter->QueryInterface(IID_ITruck, (void**)&m_pTruck);

// release reference to outer object here and DO NOT

// release it later in the object's destructor

// освобождаем здесь ссылку на внешний объект и

// НЕ ОСВОБОЖДАЕМ ее потом в деструкторе объекта

if (SUCCEEDED(hr)) m_pTruck->Release();

}

Этот способ работает, поскольку время жизни внутреннего объекта является точным подмножеством времени жизни внешнего объекта. Это означает, что m_pTruck будет теоретически всегда указывать на существующий объект. Конечно, если внешний объект реализовал ITruck как отделяемый интерфейс, то все предыдущее неверно, так как вызов Release уничтожит этот отделяемый интерфейс.

Объекты, которые агрегируют другие объекты, должны быть в курсе проблем, возникающих при запросе интерфейсных указателей внутренними объектами агрегата. В дополнение к уже сделанному предостережению относительно отделяемых интерфейсов отметим еще одну возможную опасность, связанную со стабилизацией объекта. Когда клиенты обращаются к объекту, он должен находиться в стабильном состоянии. В частности, его счетчик ссылок не должен равняться нулю. В общем случае это не является проблемой, так как клиенты могут получать интерфейсные указатели только через QueryInterface, который всегда освобождает AddRef раньше, чем возврат. Однако если объект создает агрегат в своем разработчике, в то время как его счетчик ссылок объекта равен нулю, то программа инициализации внутреннего объекта, показанная выше, освободит завершающее освобождение внешнего объекта, побуждая тем самым внешний объект к преждевременному самоуничтожению. Чтобы устранить эту проблему, объекты, агрегирующие другие объекты, временно увеличивают свои счетчики ссылок на единицу на время создания агрегируемых объектов:

Outer::Outer(void)

{

++m_cRef;

// protect against delete this

// защищаем против удаления this

CoCreateInstance(CLSID_Inner, this, CLSCTX_ALL, IID_IUnknown, (void**)&m_pUnkInner);

–m_cRef;

// allow delete this

// позволяем удалить this }

Данная методика стабилизации предотвращает преждевременное разрушение, когда внутренний объект освобождает указатели, которые он, быть может, получил в свой код инициализации. Эта методика настолько общепринята, что большинство СОМ-оболочек программирования включают в себя явный метод перекрытия (overridable), который работает внутри области действия пары инкремент/декремент. В MFC (Microsoft Foundation Classes – библиотека базовых классов Microsoft) этот метод называется CreateAggregates, в ATL – FinalConstruct.

Поскольку показанные выше методики реализации агрегируемого объекта не требуют никаких дополнительных базовых классов, кроме классов C++, то альтернативная форма макроса IMPLEMENT_UNKNOWN может прозрачно реализовать раздвоенную реализацию IUnknown. Определение исходного класса:

class Car : public ICar

{

Car(void);

IMPLEMENT_UNKNOWN(Car)

BEGIN_INTERFACE_TABLE(Car)

IMPLEMENTS_INTERFACE(ICar)

IMPLEMENTS_INTERFACE(IVehicle)

END_INTERFACE()

// IVehicle methods

// методы IVehicle

STDMETHODIMP GetMaxSpeed(long *pn);

// ICar methods

// методы ICar

STDMETHODIMP Brake(void);

};

просто переводится в следующее:

class Car : public ICar

{

Car(void);

//indicate that aggregation is required

// показываем, что требуется агрегирование

IMPLEMENT_AGGREGATABLE_UNKNOWN(Car)

BEGIN_INTERFACE_TABLE(Car)

IMPLEMENTS_INTERFACE(ICar)

IMPLEMENTS_INTERFACE(IVehicle)

END_INTERFACE()

// IVehicle methods

// методы IVehicle

STDMETHODIMP GetMaxSpeed(long *pn);

// ICar methods

// методы ICar

STDMETHODIMP Brake(void);

};

Встроенное расширение макроса IMPLEMENT_AGGREGATABLE_UNKNOWN включено в код, приложенный к этой книге.

Не все классы способны к агрегированию. Для того чтобы выставить неагрегируемые классы как часть индивидуальности другого объекта, необходимо, чтобы внешние объекты явно передавали вызовы методов внутренним объектам. Эта технология СОМ часто называется включением (containment).

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

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