208

EXPORT LPMALLOC CreateAllocator();

//-------------------------------------------------------------------

// Implementation of allocator interface //-------------------------------------------------------------------

#undef INTERFACE #define INTERFACE DAlloc

DECLARE_INTERFACE_(DAlloc, IMalloc)

{

// *** IUnknown methods ***

STDMETHOD (QueryInterface)(THIS_ REFIID riid, LPVOID FAR *ppv);

STDMETHOD_(ULONG, AddRef) (THIS);

STDMETHOD_(ULONG, Release)(THIS);

#ifndef CINTERFACE public :

DAlloc();

~DAlloc();

BOOL Initialize();

private :

ULONG RefCount;

HANDLE hHeap;

#endif

};

Рис. 20.2 Библиотека IMALLOC

Для того, чтобы увидеть эту процедуру выделения памяти в действии, запустите файл CALLER.EXE, который загружает и использует библиотеку IMALLOC.DLL.

IMALLOC.DLL

Как закрытый компонент OLE библиотека IMALLOC демонстрирует свой интерфейс IMalloc посредством указателя интерфейса, являющегося возвращаемым значением закрытой экспортируемой функции CreateAllocator. Сами функции интерфейса экпортировать не нужно, поскольку возвращаемый указатель интерфейса полностью обеспечивает доступ ко всем его функциям. Функция CreateAllocator выделяет память для экземпляра DAlloc, объекта С++, который помещается в защищенную "кучу" Win32 , и чья таблица виртуальных функций соответствует двоичному стандарту, определенному для интерфейса IMalloc. Указатель на объект DAlloc — это указатель на интерфейс IMalloc. Такое преобразование типа осуществляется в функции CreateAllocator:

return(LPMALLOC) pAllocator;

Поскольку функция CreateAllocator определяется в файле с исходным текстом на С++, требуется специальная обработка, чтобы запретить искажение имен, вносимое С++, и обеспечить возможность вызова этой функции из С. Эту задачу выполняют следующие строки из файла IMALLOC.H:

#define EXPORT extern "C" __declspec(dllexport)

EXPORT LPMALLOC CreateAllocator();

Ключевое слово EXPORT мы определили в главе 19.

Замечание для программистов на языке С

Библиотека IMALLOC написана на С++, поэтому некоторые термины и соглашения могут быть вам незнакомы. Внутри функции CreateAllocator оператор new выделяет область памяти для объекта DAlloc (путем вызова функции malloc), а затем вызывается его конструктор DAlloc::DAlloc, который выполняет инициализацию данных

209

— членов объекта. Оператор delete вызывается из функции CreateAllocator, если инициализация не прошла, и освобождает память объекта в случае ошибки. Это функция аналогична вызову функции free, за которой следует вызов функции-деструктора для удаления (или очистки) объекта DAlloc::~DAlloc.

Замечание для программистов на языке С

Оператор разрешения области видимости (::) указывает на принадлежность функции конкретному классу С++. В IMALLOC такое обозначение показывает, что функция GetSize является членом класса DAlloc:

DAlloc::GetSize (...)

Хотя все функции, перед именами которых стоит DAlloc::, являются членами класса DAlloc, не все функции-члены входят в таблицу функций класса DAlloc, а только те, которые объявлены с ключевым словом virtual. В файле IMALLOC.H макросы STDMETHOD и STDMETHOD_ (о чем подробно будет рассказано позже) содержат ключевое слово virtual.

Отличие между IMalloc и DAlloc в порядке их реализации. Как контракт на услуги, интерфейс не может иметь реализацию, непосредственно ассоциированную с ним. В терминах С++ это требование удовлетворяется тем, что все интерфейсы делаются абстрактными классами, то есть чистыми интерфейсами безо всякой реализации. Следовательно DAlloc (префикс "D" означает "производный класс, derived class") использует IMalloc в качестве базового класса, от которого он наследует свои виртуальные функции-члены.

Но, учитывая наличие трех дополнительных функций-членов — DAlloc, ~DAlloc и Initialize — и двух дополнительных данных-членов — RefCount и hHeap — является ли DAlloc правильной реализацией IMalloc? Ответ — да, является. Три дополнительные функции не являются виртуальными (они не объявлены с ключевым словом virtual), следовательно, они не влияют на таблицу виртуальных функций, которая в терминах OLE представляет собой таблицу функций интерфейса. Поскольку в DAlloc имеется таблица функций интерфейса, которая соответствует таблице, необходимой для выполнения того, что определяет IMalloc, то эти три дополнительные функции не играют роли. Как и данные-члены, они игнорируются, поскольку интерфейсы OLE определяются в С++ как классы без данных (data-free). DAlloc может использовать эти данные-члены для собственных целей, поскольку они не участвуют в выполнении контракта, что необходимо для интерфейса OLE в общем и для интерфейса IMalloc в частности.

Теперь о макросах

Одним из аспектов определения интерфейса, который поначалу может вызвать путаницу, является использование ряда макросов типа DECLARE_INTERFACE, STDMETHOD и THIS. Смысл этих макросов состоит в том, чтобы сделать коды OLE переносимыми, как для клиента, так и для сервера. Эти макросы способствуют улучшению переносимости интерфейсов OLE двумя путями: во-первых, макросы определены и на С, и на С++, что обеспечивает доступ к интерфейсу на обоих языках. Во-вторых, макросы помогают поддерживать переносимость для операционных систем разных платформ.

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

#undef INTERFACE

#define INTERFACE IUnknown

DECLARE_INTERFACE(IUnknown)

{

STDMETHOD(QueryInterface)(THIS_ REFIID riid, LPVOID FAR *ppvObj) PURE;

STDMETHOD_(ULONG, AddRef)(THIS) PURE;

STDMETHOD_(ULONG, Release)(THIS) PURE;

};

Многие макросы имеют две версии определения интерфейса: обычная версия и расширенная версия, в именах макросов которой имеется суффикс _. В объявлении интерфейса IUnknown имеются примеры обеих версий: STDMETHOD и STDMETHOD_. В обеих версиях функции интерфейса объявляются виртуальными, и обе используют специальное соглашения для вызова функций (__stdcall в Win32). Но STDMETHOD означает, что типом возвращаемого значения является HRESULT. Другие же типы возвращаемого значения должны быть заданы в качестве параметров макроса STDMETHOD_.

В следующей таблице суммируется роль объявления интерфейса и определения макросов:

211

Переносимость между платформами означает наличие запаса специфических для платформы ключевых слов. Например, для интерфейсов OLE Win16 при компоновке требуются ключевые слова __far и __pascal. В Win32 эти два слова заменены на __stdcall, как соглашение для вызова всех функций интерфейсов. Макросы обеспечивают метку-заполнитель для ключевых слов, которые нельзя использовать при создании, поскольку, фактически, компоненты OLE могут создаваться для работы в системе Apple Macintosh, реализациях OLE в UNIX или в OS/400, VMS или MSV. Специфический для платформы набор включаемых файлов будет определять специфические для среды ключевые слова там, где они необходимы.

Услуги, предоставляемые интерфейсом IUnknown

Хотя в библиотеке IMALLOC.DLL показана реализация интерфейса IMalloc, более интересной ее чертой является реализация трех функций — членов IUnknown и двух услуг, обеспечиваемых этими функциями: управлением временем жизни компонента и поддержкой многоинтерфейсного компонента.

Управление временем жизни компонента

Жизнь компонента OLE определяется одним закрытым членом данных и двумя функциями интерфейса. Членом данных является счетчик ссылок — значение типа ULONG, названное в DAlloc RefCount, а двумя функциями интерфейса — AddRef и Release.

Библиотека IMALLOC создает компонент — процедуру выделения памяти, когда вызывается функция CreateAllocator, функция создания закрытого компонента. Ниже приведены соответствующие строки программы внутри функции CreateAllocator:

DAlloc *pAllocator = new DAlloc();

if(pAllocator != NULL && pAllocator -> Initialize( ))

{

pAllocator -> AddRef();

}

else

{

delete pAllocator;

}

Когда создается объект, в конструкторе DAlloc его счетчик ссылок инициализируется нулем. В то же самое время описатель "кучи" Win32 устанавливается в NULL:

DAlloc::DAlloc( )

{

RefCount = 0;

hHeap = NULL;

}

В С++ программирование упрощается благодаря тому, что работа конструкторов класса, как только что показано, ограничивается только инициализацией данных-членов. Смысл в том, что конструкторам непросто известить функцию-создателя объекта о неблагоприятных условиях, следовательно они выполняют только то, что не может не получиться. Те задачи, которые могут потерпеть неудачу, часто передаются специальным функциям инициализации, таким как функция Initialize в DAlloc, которая создает "кучу" Win32, необходимую для удовлетворения запросов на выделение памяти интерфейса IMalloc.

После того, как функция CreateAllocator должным образом создала и инициализировала объект DAlloc, она с помощью функции AddRef увеличивает на 1 значение счетчика ссылок. Эта функция определяется следующим образом:

STDMETHODIMP_(ULONG)

DAlloc::AddRef(void)

{

return ++RefCount;

}

Теперь становится понятно, почему типом возвращаемого значения этой функции не является тип HRESULT: оно позволяет вызывающей функции узнать текущее значение счетчика ссылок (но им можно пользоваться только в целях отладки).

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