Сущность технологии СОМ. Библиотека программиста - [31]
PugCat::QueryInterface(REFIID riid, void **ppv)
{
assert(ppv != 0);
// or return EPOINTER in production
// или возвращаем EPOINTER в реальный продукт
if (riid == IIDIPug) *ppv = staticcast
else if (riid == IIDIDog) *ppv = staticcast
else if (riid == IIDIAnimal)
// cat or pug?
// кот или мопс?
*ppv == staticcast
else if (riid == IIDIUnknown)
// cat or pug?
// кот или мопс?
*ppv = staticcast
else if (riid == IIDICat) *ppv = staticcast
else
{
// unsupported interface
// неподдерживаемый интерфейс
*ppv = 0;
return ENOINTERFACE;
}
// if we reach this point, *ppv is non-null
// and must be AddRef'ed (guideline A2)
// если мы дошли до этого места, то *ppv ненулевой
// и должен быть обработан AddRef'ом ( принцип A2)
reinterpretcast
return SOK;
}
Использование staticcast более предпочтительно, чем традиционные приведения типа в стиле С:
*ppv = (IPug*)this;
так как вариант staticcast вызовет ошибку этапа компиляции, если произведенное приведение типа не согласуется с существующим базовым классом.
Заметим, что в показанной здесь реализации QueryInterface при запросе на интерфейс, поддерживающийся более чем одним базовым интерфейсом (например, IUnknown, IAnimal) приведение типа должно явно выбрать более определенный базовый класс. Например, для класса PugCat такой вполне безобидно выглядящий код не откомпилируется:
if (riid == IIDIUnknown) *ppv = staticcast
Этот код не пройдет компиляцию, поскольку такое приведение типа является неоднозначным и может соответствовать более чем одному базовому классу. Это было показано в случае FastString и IExtensibleObject из предыдущей главы. Вместо этого реализация должна более точно выбрать тип для приведения:
if (riid == IIDIUnknown) ppv = staticcast
или if (riid == IIDIUnknown) ppv = staticcast
Каждый из этих двух фрагментов кода допустим для реализации PugCat. Первый вариант предпочтительнее, так как многие компиляторы выдают несколько более эффективный код, когда использован крайний левый базовый класс[1].
Использование указателей интерфейса СОМ
Программисты C++ должны использовать методы IUnknown явно, потому что перевод модели СОМ на язык C++ не предусматривает использования среды поддержки выполнения (runtime layer) между кодом клиента и кодом объекта. Поэтому IUnknown можно рассматривать просто как набор обещаний, которые все программисты СОМ дают друг другу. Это дает преимущество программистам C++, так как C++ может создавать код, который потенциально более эффективен, чем языки, которые требуют такого динамического слоя при работе с СОМ.
При работе на Visual Basic и Java, в отличие от C++, программисты никогда не видят QueryInterface, AddRef или Release. Для этих двух языков детали IUnknown надежно скрыты за поддерживающей эти языки виртуальной машиной. На Java QueryInterface просто отображается в приведение типа:
public void TryToSnoreAndIgnore(Object obj)
{
IPug pug;
try
{
pug = (IPug)obj;
// VM calls QueryInterface
// VM вызывает QueryInterface
pug.Snore();
}
catch (Throwable ex)
{
// ignore method or QI failures
// игнорируем сбой метода или QI
}
ICat cat;
try
{
cat = (ICat)obj;
// VM calls QueryInterface
// VM вызывает QueryInterface
cat.IgnoreMaster();
}
catch (Throwable ex)
{
// ignore method or QI failures
// игнорируется сбой метода или QI
}
}
Visual Basic не требует от клиентов приведения типов. Вместо этого, когда указатель интерфейса присваивается переменной неподходящего типа, виртуальная машина (VM) Visual Basic молча вызывает QueryInterface от имени клиента:
Sub TryToSnoreAndIgnore(obj as Object)
On Error Resume Next
' ignore errors
' игнорируем ошибки
Dim pug as IPug
Set pug = obj
' VM calls QueryInterface
' VM вызывает QueryInterface
If Not (pug is Nothing)
Then pug.Snore
End
if Dim cat as ICat
Set cat = obj
' VM calls QueryInterface
' VM вызывает QueryInterface
If Not (cat is Nothing)
Then cat.IgnoreMaster
End if End Sub
Обе виртуальные машины, как Java, так и Visual Basic, выбросят при сбое QueryInterface исключения. В обеих средах виртуальная машина автоматически преобразует языковую концепцию живучести переменной в явные вызовы AddRef и Release , избавляя клиента и от этой подробности.
Одна методика, потенциально способная упростить использование в СОМ интерфейсных указателей из C++, состоит в том, чтобы скрыть их в классе интеллектуальных указателей. Это устраняет необходимость необработанных (raw ) вызовов методов IUnknown. В идеале интеллектуальный указатель СОМ будет:
Корректно обрабатывать каждый вызов Add/Release во время присваивания.
Автоматически уничтожать интерфейс в деструкторе, что снижает возможность утечки ресурса и повышает безопасность (надежность) исключений.
