静态CComPtr变量

时间:2010-06-15 09:36:44

标签: visual-c++ com static object-destruction

在应用程序中使用静态CComPtr成员变量是不明智的。 因为我们无法控制静态变量的破坏,所以它可能在CoUninitialze之后发生。

3 个答案:

答案 0 :(得分:2)

如果您采取适当的预防措施,那么使用CComPtr作为静态成员本身并不是邪恶的。

通过“适当的预防措施”,我的意思是你应该考虑:

  • Mutexing访问它;
  • 确保已初始化 使用前;
  • 为您自己的类维护一个互斥的静态实例计数;
  • 当实例计数达到零时,确保在类'自己的CComPtr::Release方法中调用FinalRelease

答案 1 :(得分:0)

无论如何,这是一个坏主意

答案 2 :(得分:0)

正如谢尔盖在评论中所说,我觉得这很糟糕。静态对象的析构函数在主终止后调用,如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不应该是静态的。