CComPtr和std :: shared_ptr的互操作性

时间:2017-07-17 12:47:23

标签: c++ com shared-ptr

考虑以下方案。有一个ATL包装的C ++类(CMyComClass实现IMyComClass),这个类用于异步操作,因此它(应该派生)派生自std::enable_shared_from_this以提供shared_from_this()(而不是将this传递给异步函数,这将确保在调用异步操作时对象仍然存在。另一方面,有一个COM接口,例如可以要求将上述类作为com对象返回,类似于get(IUnknown** myobject)addObject(IUnkown* mynewobject)来添加对象。在这种情况下,我陷入僵局,我不能从COM获取原始指针并分配给shared_ptr,因为我没有转移所有权,shared_ptr的引用计数将是错误的,因为它不会计算以前的COM引用,此外shared_ptr计数的增加不会影响CComPtr引用计数,这意味着指针可能随时被销毁。此外还有CMyComClass的成员函数,可以创建,例如std::async操作,将this传递给它,再次,包装COM可以被销毁,我将留下悬空指针。有办法克服这个问题吗? shared_from_this上有IUnknown的等价物。
是的,我知道,设计有缺陷,没有,我现在无法改变它。
EDIT001: 我想我的问题过于复杂。 让我们从根本问题开始。 考虑遵循COM类

class ATL_NO_VTABLE CMyComObject
    : public CComObjectRootEx<CComMultiThreadModel>,
      public CComCoClass<CMyComObject, &CLSID_MyComObject>,
      public IDispatchImpl<IMyComObject, &IID_IMyComObject, &LIBID_ATLProject2Lib, /*wMajor =*/1, /*wMinor =*/0>
{
public:
    CMyComObject() { m_pUnkMarshaler = NULL; }

    DECLARE_REGISTRY_RESOURCEID(IDR_MYCOMOBJECT)

    BEGIN_COM_MAP(CMyComObject)
    COM_INTERFACE_ENTRY(IMyComObject)
    COM_INTERFACE_ENTRY(IDispatch)
    COM_INTERFACE_ENTRY_AGGREGATE(IID_IMarshal, m_pUnkMarshaler.p)
    END_COM_MAP()

    DECLARE_PROTECT_FINAL_CONSTRUCT()
    DECLARE_GET_CONTROLLING_UNKNOWN()

    HRESULT FinalConstruct()
    {
        m_asyncTask = std::async(std::launch::async, [self{this}]() { std::cout << typeid(self).name() << std::endl; });
        return CoCreateFreeThreadedMarshaler(GetControllingUnknown(), &m_pUnkMarshaler.p);
    }

    void FinalRelease() { m_pUnkMarshaler.Release(); }

    CComPtr<IUnknown> m_pUnkMarshaler;

private:
    std::future<void> m_asyncTask;
};

注意std::async中的FinalConstruct(不是最合适的地方,但假装它是常规COM方法),调用async,调度任务,然后调度实例(实例)例如,由于实例的引用计数降为零,因此销毁了COM对象)。显然,计划任务将失败,假设有访问冲突。怎么会阻止它发生?

EDIT002:仅适用于lulz
瞧,解决方案!

class ATL_NO_VTABLE CMyComObject
    : public CComObjectRootEx<CComMultiThreadModel>,
      public CComCoClass<CMyComObject, &CLSID_MyComObject>,
      public IDispatchImpl<IMyComObject, &IID_IMyComObject, &LIBID_ATLProject2Lib, /*wMajor =*/1, /*wMinor =*/0>
{
public:
    CMyComObject()
        : m_pUnkMarshaler(nullptr), m_self(this, [](CMyComObject* p) {
              // check if still have COM references
              if(p->m_dwRef == 0)
                  delete p;
          })
    {
    }

    DECLARE_REGISTRY_RESOURCEID(IDR_MYCOMOBJECT)

    BEGIN_COM_MAP(CMyComObject)
    COM_INTERFACE_ENTRY(IMyComObject)
    COM_INTERFACE_ENTRY(IDispatch)
    COM_INTERFACE_ENTRY_AGGREGATE(IID_IMarshal, m_pUnkMarshaler.p)
    END_COM_MAP()

    DECLARE_PROTECT_FINAL_CONSTRUCT()
    DECLARE_GET_CONTROLLING_UNKNOWN()

    HRESULT FinalConstruct()
    {
        m_asyncTask = std::async(
            std::launch::async, [self{SharedFromThis()}]() { std::cout << typeid(self).name() << std::endl; });
        return CoCreateFreeThreadedMarshaler(GetControllingUnknown(), &m_pUnkMarshaler.p);
    }

    void FinalRelease() { m_pUnkMarshaler.Release(); }

    ULONG InternalRelease()
    {
        if(m_dwRef > 0)
        {
            _ThreadModel::Decrement(&m_dwRef);
        }
        // Dont let COM delete the instance if there is shared ptrs in the wild
        return m_dwRef + m_self.use_count();
    }
    std::shared_ptr<CMyComObject> SharedFromThis() { return m_self; }

    CComPtr<IUnknown> m_pUnkMarshaler;

private:
    std::future<void> m_asyncTask;
    std::shared_ptr<CMyComObject> m_self;
};

这将是一个很好的优雅解决方案,效果很好。但是,类本身持有对象的一个​​引用,因此std::shared_ptr的删除将永远不会启动。唉!做正确的事情并从COM类中获取内容,然后将提取的内容保存为COM类中的shared_ptr

2 个答案:

答案 0 :(得分:4)

正如其他人所提到的,COM在跨线程使用接口方面有相当严格的规则,而你只是通过不遵守这些规则来引发错误。这是许多COM开发人员将其核心逻辑创建为C ++类,然后将这些C ++类包装在瘦COM对象中的众多原因之一。这是我的建议。你的核心对象应该没有任何COM意识。如果它当前具有作为其他COM接口指针的数据成员,则执行相同的操作 - 将该子对象提取到C ++类中,并为父对象的COM包装器所拥有的子对象提供COM包装。 p>

class CMyObject : std::enable_shared_from_this
{
public:
    void Startup()
    {
        // non-COM stuff
        auto self = shared_from_this();
        m_asyncTask = std::async(std::launch::async, [self]() {
             std::cout << typeid(self).name() << std::endl;
        });
    }
private:
    std::future<void> m_asyncTask;
}

class ATL_NO_VTABLE CMyComObject
    : public CComObjectRootEx<CComMultiThreadModel>,
      public CComCoClass<CMyComObject, &CLSID_MyComObject>,
      public IDispatchImpl<IMyComObject, &IID_IMyComObject, &LIBID_ATLProject2Lib, /*wMajor =*/1, /*wMinor =*/0>
{
    ...
    HRESULT FinalConstruct()
    {
        m_internal = make_shared<CMyObject>();
        m_internal->Startup();
        // COM stuff
        return CoCreateFreeThreadedMarshaler(GetControllingUnknown(), &m_pUnkMarshaler.p);
    }
    ...
private:
    shared_ptr<CMyObject> m_internal;
    ...
}

答案 1 :(得分:0)

直截了当的方法不是混合使用C ++和COM引用计数器,而是为COM接口创建一个瘦C ++包装器对象,它本身可以用于异步操作:

class t_MyComClassWrapper: std::enable_shared_from_this< t_MyComClassWrapper >
{
    private: CComPtr< IMyComClass > m_p_my_class;

    public: t_MyComClassWrapper(void)
    :    m_p_my_class(new CMyComClass)
    {}

    // TODO forward IMyComClass methods...
};

auto p_wrapper(::std::make_shared< t_MyComClassWrapper >());

此设计将确保在C ++和COM引用计数器都降为0之前不会销毁对象。