在应用程序中拥有静态 CComPtr 成员变量是不是坏主意。由于我们无法控制静态变量的破坏，它可能发生在 CoUninitialze 之后。
问问题
672 次
3 回答
3
如果您采取了适当的预防措施，那么使用 aCComPtr作为静态成员并不是天生的坏事。
通过“适当的预防措施”，我的意思是您应该考虑：
- 对它的访问进行互斥；
- 确保在使用前已初始化；
- 为您自己的类维护一个互斥的静态实例计数；
- 确保在实例计数达到零时
CComPtr::Release在您的类自己的方法中调用它。FinalRelease
于 2010-06-15T10:49:54.587 回答
0
无论如何，这是个坏主意
于 2010-06-16T22:50:42.250 回答
0
正如谢尔盖在评论中所说，我认为这很糟糕。静态对象的析构函数在 main 终止后调用，如 C++03 标准的第 3.6.3 节所述：
静态存储持续时间（在块范围或命名空间范围声明）的初始化对象的析构函数（12.4）作为从 main 返回的结果和调用 exit（18.3）的结果被调用。这些对象的销毁顺序与其构造函数完成或动态初始化完成的相反。如果对象是静态初始化的，则对象的销毁顺序与动态初始化对象的顺序相同。对于数组或类类型的对象，该对象的所有子对象在销毁任何具有在子对象构造期间初始化的静态存储持续时间的本地对象之前被销毁。
并在这里演示：http ://www.geeksforgeeks.org/static-objects-destroyed/ 。
但是在 Main 终止之前调用了清理主线程上的 COM 库的CoUninitialize 。CoUninitialize 将按照 msdn 文档中的说明清理所有剩余资源。我们应该在调用 CoUninitialize 之前调用 COM 对象的 Release 方法，因为之后它们将不再存在，因此我们应该确保在调用 CoUninitialize 之前调用 CComPtr 析构函数。因此，不应将 CComPtr 设为静态。
于 2017-09-06T06:45:28.770 回答