А. Легалов - Применение Windows API

Что сказать о подсчете ссылок? Вполне очевидно, что имеются очень немного потребностей в подсчете ссылок (refcounting), пока Вы соглашаетесь не уничтожать объект, в то время пока Вы используете его интерфейсы. Это не такое большое дело. Мы делаем это все время, когда используем методы в C++. Мы не думаем о том, что это особенно жесткое требование: не уничтожить объект, в то время как мы используем его методы. Если мы должны следовать за текущей моделью OLE везде, мы должны требовать, чтобы клиент получал счетчик ссылок любого метода, который он, или она планируют использовать, а затем освобождать его после вызова? Это было бы абсурдно, не так ли?

Так, почему же OLE так придирчиво считает ссылки? Простое объяснение: потому что это скрывает объект от клиента. OLE-объект создается неявно, когда Вы получаете его первый интерфейс, и разрушается неявно, когда Вы освобождаете его последний интерфейс. Вы видите, что OLE делает для Вас большую пользу, скрывая эту бухалтерию от Вас. Так ли это? Забавный вопрос.

Давным давно, когда машинные языки были все еще в их младенчестве, мастера C, пробовали реализовать стек. Они сделали открытие, что всем клиентам нуждающимся в стеке нужны были две функции, втолкнуть (push) и вытолкнуть (pop). Они также поняли (реализовали), что они должны будут выделить некоторую память, чтобы хранить данные стека и, так как они были опрятные программисты, они будут должны были освободить их, когда клиент был обслужен. Но как они узнали бы, когда клиент был обслужен? Совершенно очевидно, что клиент был обслужен, когда он или она не должны были бы большк выполнять вызовы push или pop. Как только мастера C поняли это, остаток был прост. Стек был создан и память распределялась, когда клиент впервые запрашивал push. Он мог затем вызывать push со специальным параметром, чтобы получить соответствующее pop. Фактически, используя эту схему, он мог создавать столько push и pop, сколько он желал. Затем, когда он был обслужен с заданными push или pop, он просто освобождал бы их. Однократное освобождение всех вталкиваний и выталкиваний привело бы к освобождению стека. Эта гениальная схема чрезвычайно упрощала программирование, потому что клиенты не должны были иметь дело со стеком непосредственно. Система вела всю бухгалтерию. Программисты были в экстазе, и они отдали все их деньги мастерам C. Между прочим, новые функции назывались i_push и i_pop.

Здесь самая лучшая часть истории. Вы могли бы подумать: «О, право, большое дело! Легко придумать эти идеи теперь, после того, как OLE находится на рынке для почти десятилетие». Сообщаю, что искренне Ваш был тем, кто работал когда-то в Microsoft. Вскоре, после выпуска OLE 1.0, я записал эти идеи и послал ответственным людям. Короче говоря, идеи были приняты как допустимые, но отклонены, потому что уже имелось слишком много кода, записанного в спецификациях OLE (обычное дело в Microsoft). Никто из менеджеров не пожелал рисковать, перепроектируя OLE.

Итак, теперь мы имеем подсчет ссылок, агрегацию и все прочее. Мораль истории:

Нет ничего святого, что касается OLE. Это может быть сделано лучше!

Но мы все же можем иметь пирог и есть его? Другими словами, можно формировать «интеллектуальное OLE» на вершине «другого OLE»? Ваша ставка! Идите прямо к следующей обучающей программе.

Перевод А. И. Легалова

Англоязычный оригинал находится на сервере компании Reliable Software

Прежде всего Вы должны сообщить миру, что собираетесь использовать OLE. Имеется небольшой класс, который будет делать это за Вас. Только внедрите объект этого класса в некоторый высокоуровневый сконструированный объект прежде, чем Вы что-либо сделаете с OLE и удалите его после того, как отработаете с OLE. В Windows программе первоосновой для UseOle является «Контроллер».

class UseOle {

public:

UseOle() { OleInitialize (0); }

~UseOle() { OleUninitialize (); }

};

class Controller {

public:

Controller(HWND hwnd, CREATESTRUCT* pCreate);

~Controller() { PostQuitMessage(0); }

void Paint(HWND hwnd);

private:

UseOleuseOle;

};

Затем Вы должны создать OLE объект, который является поставщиком интерфейсов. Абстрактный класс CoObject объявляет метод AcquireInterface. Фактический класс SObject (интеллектуальный объект) обеспечивает одну специфическую реализацию CoObject, которая использует, внутри себя, позорящий OLE IUnknown.

class CoObject{

public:

virtual void* AcquireInterface (IID const& iid) = 0;

};

class SObject: public CoObject{

public:

SObject(CLSID const& classId, bool running = false);

~SObject() {

if (_iUnk) _iUnk-> Release();

}

void* AcquireInterface(IID const& iid);

private:

IUnknown * _iUnk;

};

Давайте взглянем на реализации конструктора и метода AcquireInterface.

Конструктор получает объект, вызывая функцию API GetActiveObject и/или CoCreateInstance. Различие между ними в том, что GetActiveObject пытается овладеть уже выполняющимся объектом, в то время как CoCreateInstance пробует то же самое, но, если это терпит неудачу, то запускает любой exe-шник, необходимый для выполнения этого объекта. Некоторые объекты фактически определяют предпочтение: они хотят, чтобы новый сервер был заново запущен каждый раз, когда вызывается CoCreateInstance. GetActiveObject позволяет Вам обойти это.

Обратите внимание, что это — только один пример того, как Вы получаете доступ к OLE объектам. Вы можете захотеть поиграть с некоторыми из параметров. Например, я передаю CLSCTX_SERVER как параметр в CoCreateInstance. Это даст мне уверенность, что объект будет жить в отдельном от клиента процессе. Во многих случаях вам лучше иметь объект как сервер в процессе на основе DLL, которая загружается в адресное пространство клиента. Для больших подробностей ищите описание CoCreateInstance в вашей справке.

SObject::SObject(CLSID cons & classId, bool running) :_iUnk (0) {

HRESULT hr = S_OK;

if (running) {

:: GetActiveObject(class i d, 0, &_iunk);

}

if (_iUnk == 0) {

hr = :: CoCreateInstance(classId, 0, CLSCTX_SERVER, IID_IUnknown, (void**)&_iUnk);

}

if (FAILED(hr)) throw HEx(hr, "Couldn't create instance");

}

Через мгновение я объясню странный тип исключения HEx.

В нашей реализации AcquireInterface просто вызывает метод QueryInterface из IUnknown (или, как я говорю, неудачный QueryInterface из неудачного IUnknown).

void* SObject::AcquireInterface(IID const& iid) {

void * p = 0;

HRESULT hr = _iUnk-> QueryInterface(iid, &p);

if (FAILED(hr)) {

if (hr == E_NOINTERFACE) throw "No such interface";

else throw HEx(hr, "Couldn't acquire interface");

}

return p;

}

Метод AcquireInterface — один из этих исключительных, Получающих методов Управления ресурсами, которые освобождают ресурсы. Мы не вызываем его иначе, как внутри конструктора интеллектуального указателя интерфейса. (Между прочим, параметр шаблона — это IID указатель, потому что компилятор не будет принимать ссылки как параметры шаблона. Я не уверен почему.)