我是否完全否定了Microsoft :: WRL :: ComPtr的好处，并将它作为参考＆传递给它？

我一直在我的代码周围的ComPtrs折腾，因为我需要他们在这里那里，但我一直这样做：

HRESULT Material::Initialize(aimaterial* pMaterial,Microsoft::WRL::ComPtr<ID3D11Device1> & d3dDevice,Microsoft::WRL::ComPtr<ID3D11DeviceContext1> & d3dContext)

这是否完全否定了ComPtr的参考计数好处？ 我应该做一个价值传递（不），而不是？

感谢您的阅读

在多个节点上发生MPI_Bcast错误

'“SDL.h”编译时没有find这样的文件或目录“

错误：在我的Makefile中“混合隐式和静态模式规则”

数据报pipe道可以在Linux？

错误：'_hypot'未在此范围内声明

如何在Linux上的同一物理内存映射两个虚拟地址？

wait（0）在从fork（）创build的两个进程中调用时是否执行任何操作？

MongoDB CountAsync和游标不能在Windows服务中使用新的驱动程序

如何知道磁盘是基本的还是dynamic的？

C ++ Win32单选button背景颜色

这是完全可以的，最好是传递给const＆。

从语义角度来看，价值传递是可以接受的，而不是从性能角度考虑，因为通过这样的方式会导致上下游的冲突，这两者都是“互锁”的操作，并带来严重的后果。 而我们没有得到任何回报。

ComPtr的好处是它允许正确匹配发布调用，这太容易搞砸了，即使很容易，代码的混乱也是令人不快的。

不，你做对了。 被叫方不必修改引用计数，除非在呼叫后需要保持接口访问。 增加和减少引用计数不是免费的 – 这是一个虚拟的调用加上一个互锁的增量或减量 – 所以你无论如何都会获得更好的性能。 你应该使用一个const引用 – 甚至只是传递一个原始指针。

是的，在我的DirectX代码中，我安排我的引擎来明确哪个对象有权管理DirectX COM对象的生命周期。 然后我把它作为原始指针传递给需要它们的方法（我避免让成员变量尽可能地跟踪DX对象）。