Крестопроблемы. COM интерфейсы, множественное наследование + WRL / Общее / Форум / Программирование игр

Понадобилось работать именно с COM интерфейсами. Решил я тут воспользоваться WRL, чтобы не городить собственные QueryInterface-ы и иметь автоматически подсчет ссылок.

Но что-то встал в ступор, как его собственно использовать?
Сначала я написал 2 интерфейса:

interface DECLSPEC_UUID("{F1DFE67A-B796-4B95-ADE1-8AA030A7546D}") ITest1 : public IUnknown
{
public:
    virtual void DoTest1() = 0;
};

interface DECLSPEC_UUID("{94DE17EF-8125-491A-971A-69BD06DBAB6F}") ITest2 : public IUnknown
{
public:
    virtual void DoTest2() = 0;
};

И далее написал реализацию их унаследовавшись от RuntimeClass:

class Test12 : public RuntimeClass<RuntimeClassFlags<ClassicCom>, ITest1, ITest2>
{
public:
    void DoTest1() override {
        std::cout << "DoTest1()\n";
    }
    void DoTest2() override {
        std::cout << "DoTest2()\n";
    }
};

Теперь у меня появляется новый интерфейс:

interface DECLSPEC_UUID("{E053654A-DBC9-480D-B2BE-0FB5C2E95D53}") ITest3 : public ITest2
{
public:
    virtual void DoTest3() = 0;
};

Который я хочу заметить унаследован от ITest2. Теперь я хочу расширить Test12 как-то так:

class Test3 : public Test12, public RuntimeClass<RuntimeClassFlags<ClassicCom>, ITest3>
{
public:
    void DoTest3() override {
        std::cout << "DoTest3()\n";
    }
};

То есть я унаследовался от Test12, и дописал еще один метод DoTest3.

Теперь при попытке обявления:
Test3 tst;
Я получаю:

C2259: 'Test3': cannot instantiate abstract class
due to following members:
'void ITest2::DoTest2(void)': is abstract
see declaration of 'ITest2::DoTest2'

Ладно, понятно, нужно виртуальное наследование. Пишу сюда virtual:
class Test12 : public virtual RuntimeClass<RuntimeClassFlags<ClassicCom>, ITest1, ITest2>
и ничего не меняется. Перед ITest1 и ITest2 в данной строке прописать virtual не канает. В общем никакая комбинация virtual мне не помогла.

Лаааадно. Быть может не надо создавать классы прям так грубо? Говорят надо звать Microsoft::WRL::Make(). Что ж, давайте позовем:

ComPtr<Test3> tst1 = Make<Test3>();

Теперь мы имеем:

error C2385: ambiguous access of 'Release'

Хохо. Если попробовать виртуальное наследование - то ситуация никак не меняется. По прежнему имеем ambiguous при наследовании от IUnknown.

Под спойлером весь код:

+ Показать

− Скрыть

#include <iostream>
#include <wrl.h>
             
using namespace Microsoft::WRL;

interface DECLSPEC_UUID("{F1DFE67A-B796-4B95-ADE1-8AA030A7546D}") ITest1 : public IUnknown
{
public:
    virtual void DoTest1() = 0;
};

interface DECLSPEC_UUID("{94DE17EF-8125-491A-971A-69BD06DBAB6F}") ITest2 : public IUnknown
{
public:
    virtual void DoTest2() = 0;
};

class Test12 : public RuntimeClass<RuntimeClassFlags<ClassicCom>, ITest1, ITest2>
{
public:
    void DoTest1() override {
        std::cout << "DoTest1()\n";
    }
    void DoTest2() override {
        std::cout << "DoTest2()\n";
    }
};

interface DECLSPEC_UUID("{E053654A-DBC9-480D-B2BE-0FB5C2E95D53}") ITest3 : public ITest2
{
public:
    virtual void DoTest3() = 0;
};


class Test3 : public Test12, public RuntimeClass<RuntimeClassFlags<ClassicCom>, ITest3>
{
public:
    void DoTest3() override {
        std::cout << "DoTest3()\n";
    }
};

int main()
{
    ComPtr<Test3> tst1 = Make<Test3>();

    std::cout << "Hello, world!\n";
}

Давайте поможем ~~Даше найти~~ Саше создать объект класса Test3?

Suslik
Модератор

#1
14:28, 19 мар. 2019

MrShoor
> Понадобилось работать именно с COM интерфейсами
херово тебе. ну ты там держись.

Went
Постоялец

#2
14:47, 19 мар. 2019

MrShoor
По-моему это типичная крестопроблема, точнее того, как в С++ реализуются интерфейсы. Понятно, что у тебя Test3 дважды наследует ITest2 и любое перекрытие его методов дает неоднозначность и вынос мозга. Я бы отказался от прямого наследования и получал бы необходимые интерфейсы через функции-члены. А внутри уже держал объекты-имплементации, которые бы эти интерфейсы реализовывали. Обычно этого хватает.

xruck
Постоялец

#3
(Правка: 16:02) 16:01, 19 мар. 2019

COM не работает с наследованием. В качестве хака можно сделать базовый шаблонный класс:

template <typename T>
class Test12 : public T
{
};

class Test3 : public Test12<ITest3>
{
}

Но это такое.. Именно поэтому я и отказался в свое время от COM

Zab
Постоялец

#4
16:45, 19 мар. 2019

Что ожидал то?
Что она сама в Test3 подхватит реализацию DoTest2 из Test12? С какой стати, если оно совсем из другой ветки наследования? Она что, должна по принципу "похожести" добавлять реализации всего того, что мы не запрограммировали?

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

Zab
Постоялец

#5
(Правка: 16:55) 16:53, 19 мар. 2019

Решение задачки - добавить реализацию DoTest2 в Test3:

    void DoTest2() override { Test12::DoTest2(); }

Или же сделать реализацию Test12 шаблонной и применять ее уже после наследования от ITest3

MrShoor
Участник

#6
18:41, 19 мар. 2019

Zab
> Она что, должна по принципу "похожести" добавлять реализации всего того, что мы
> не запрограммировали?
Мы как раз это запрограммировали в Test12. ITest2 - полностью абстрактный, поэтому взять имплементацию ITest2 из Test12 - было бы вполне себе нормальным решением.

> Виртуальное наследование не поможет, потому как с COM оно не совместимо.
Что значит не совместимо? Вот вполне себе рабочий COM код:

+ Показать

− Скрыть

#include <iostream>
#include <wrl.h>

using namespace Microsoft::WRL;

const IID IID_ITest1 = { 0xF1DFE67A,0xB796,0x4B95,{ 0xAD,0xE1,0x8A,0xA0,0x30,0xA7,0x54,0x6D } };
interface DECLSPEC_UUID("{F1DFE67A-B796-4B95-ADE1-8AA030A7546D}") ITest1 : public virtual IUnknown
{
public:
    virtual void DoTest1() = 0;
};

const IID IID_ITest2 = { 0x94DE17EF,0x8125,0x491A,{ 0x97,0x1A,0x69,0xBD,0x06,0xDB,0xAB,0x6F } };
interface DECLSPEC_UUID("{94DE17EF-8125-491A-971A-69BD06DBAB6F}") ITest2 : public virtual IUnknown
{
public:
    virtual void DoTest2() = 0;
};

class Test12 : public virtual ITest1, public virtual ITest2
{
public: //IUnknown
    ULONG m_cRef;

    HRESULT STDMETHODCALLTYPE QueryInterface(REFIID riid, LPVOID * ppvObj) override {
        if (!ppvObj)
            return E_INVALIDARG;
        *ppvObj = NULL;
        if (riid == IID_IUnknown)
        {
            *ppvObj = dynamic_cast<IUnknown*>(this);
            AddRef();
            return S_OK;
        }
        if (riid == IID_ITest1)
        {
            *ppvObj = dynamic_cast<ITest1*>(this);
            AddRef();
            return S_OK;
        }
        if (riid == IID_ITest2)
        {
            *ppvObj = dynamic_cast<ITest2*>(this);
            AddRef();
            return S_OK;
        }
        return E_NOINTERFACE;
    }
    ULONG STDMETHODCALLTYPE AddRef() override  {
        InterlockedIncrement(&m_cRef);
        return m_cRef;
    }
    ULONG STDMETHODCALLTYPE Release() override {
        ULONG ulRefCount = InterlockedDecrement(&m_cRef);
        if (0 == m_cRef)
            delete this;
        return ulRefCount;
    }
public:
    void DoTest1() override {
        std::cout << "DoTest1()\n";
    }
    void DoTest2() override {
        std::cout << "DoTest2()\n";
    }
};

const IID IID_ITest3 = { 0xE053654A,0xDBC9,0x480D,{ 0xB2,0xBE,0x0F,0xB5,0xC2,0xE9,0x5D,0x53 } };
interface DECLSPEC_UUID("{E053654A-DBC9-480D-B2BE-0FB5C2E95D53}") ITest3 : public virtual ITest2
{
public:
    virtual void DoTest3() = 0;
};


class Test3 : public Test12, public virtual ITest3
{
public:
    HRESULT STDMETHODCALLTYPE QueryInterface(REFIID riid, LPVOID * ppvObj) override {
        HRESULT hr = Test12::QueryInterface(riid, ppvObj);
        if (hr != E_NOINTERFACE) return hr;
        if (riid == IID_ITest3)
        {
            *ppvObj = dynamic_cast<ITest3*>(this);
            AddRef();
            return S_OK;
        }
        return E_NOINTERFACE;
    }
public:
    void DoTest3() override {
        std::cout << "DoTest3()\n";
    }
};

int main()
{
    ComPtr<IUnknown> tst0(new Test3());
    ComPtr<ITest1> tst1;
    ComPtr<ITest2> tst2;
    ComPtr<ITest3> tst3;
    
    tst0.As(&tst1);
    tst0.As(&tst2);
    tst0.As(&tst3);

    tst1->DoTest1();
    tst2->DoTest2();
    tst3->DoTest2();
    tst3->DoTest3();

    std::cout << "Hello, world!\n";
}

Только тут все приходится делать руками. Все работает, но не прикольно, что нужно перегружать QueryInterface в каждом наследнике. Собственно поэтому хотел взять RuntimeClass, чтобы оно само в QueryInterface могло, без бойлерплейт кода.

> Решение задачки - добавить реализацию DoTest2 в Test3:
> void DoTest2() override { Test12::DoTest2(); }
Отличное решение. Представь теперь, что у меня в реальной задаче ITest2 содержит 50-100 методов, и при этом наследуется 20-30 раз по различным ITest3, ITest4 и прочим интерфейсам. Сколько там получается? 1000-3000 методов вот такого бойлерплейт кода?

Went
> Понятно, что у тебя Test3 дважды наследует ITest2 и любое перекрытие его
> методов дает неоднозначность и вынос мозга.
Причина мне тоже понятна, и данную проблему как раз решает виртуальное наследование. Но как его добиться через RuntimeClass - непонятно.

> Я бы отказался от прямого наследования и получал бы необходимые интерфейсы
> через функции-члены. А внутри уже держал объекты-имплементации, которые бы эти
> интерфейсы реализовывали. Обычно этого хватает.
Слишком много бойлерплейт кода.

Zab
Постоялец

#7
18:45, 19 мар. 2019

MrShoor
> Вот вполне себе рабочий COM код
И в чем же он рабочий?

interface ITest1 : public virtual IUnknown

Это уже не COM, на двоичном уровне. Таблицы виртуальных функций другой формат получили, не совместимый с комом.

Zab
Постоялец

#8
18:48, 19 мар. 2019

MrShoor
> Представь теперь, что у меня в реальной задаче ITest2 содержит 50-100 методов,
> и при этом наследуется 20-30 раз по различным ITest3, ITest4 и прочим
> интерфейсам. Сколько там получается? 1000-3000 методов вот такого бойлерплейт
> кода?
Откуда компилятору, бедняге, знать, где у тебя функции с одинаковыми именами это одно и тоже, а где должны быть разными. Они же из разных веток, разных классов. У него нет никакой причины их совмещать, твое описание таких указаний ему не дает.

MrShoor
Участник

#9
18:53, 19 мар. 2019

Zab
> И в чем же он рабочий?
Во всём. А в чем он не рабочий?

> Это уже не COM, на двоичном уровне. Таблицы виртуальных функций другой формат
> получили, не совместимый с комом.
Чушь же.

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

void DoTest2() override { Test12::DoTest2(); }

Только сам. Не нужно это руками прописывать.