Variável estática CComPtr

Question

É uma má ideia ter variáveis ​​​​de membro CComPtr estáticas em um aplicativo.Já que não podemos controlar a destruição da variável estática e isso pode acontecer após CoUninitialze .

Answer 1

Desde que você tome as precauções apropriadas, então usando um CComPtr como um membro estático não é inerentemente mau.

Por "precauções apropriadas", quero dizer que você deve considerar:

• Mutexando o acesso a ele;
• Garantir que foi inicializado antes do uso;
• Manter uma contagem de instâncias estáticas e mutexadas para sua própria classe;
• Garantindo que CComPtr::Release é chamado na própria classe FinalRelease método quando a contagem de instâncias chega a zero.

Answer 2

é uma má ideia de qualquer maneira

Answer 3

Como Sergey disse em seu comentário, acho isso ruim.Destruidores de objetos estáticos são chamados após terminações principais conforme explicado na seção § 3.6.3 do padrão C++03:

Destruidores (12.4) para objetos inicializados com duração de armazenamento estático (declarados no escopo do bloco ou no escopo do namespace) são chamados como resultado do retorno de main e como resultado da chamada de exit (18.3).Esses objetos são destruídos na ordem inversa da conclusão de seu construtor ou da conclusão de sua inicialização dinâmica.Se um objeto for inicializado estaticamente, o objeto será destruído na mesma ordem como se o objeto fosse inicializado dinamicamente.Para um objeto do tipo array ou classe, todos os subobjetos desse objeto são destruídos antes que qualquer objeto local com duração de armazenamento estático inicializado durante a construção dos subobjetos seja destruído.

e conforme demonstrado aqui: http://www.geeksforgeeks.org/static-objects-destroyed/.

Mas CoUniinicializar que limpa a biblioteca COM no thread principal é chamado antes que Main termine.CoUninitialize limpará todos os recursos restantes conforme explicado na documentação do MSDN.Devemos chamar o método Release dos objetos COM antes que CoUninitialize seja chamado porque eles não existirão mais depois e, portanto, devemos garantir que as chamadas para o destruidor CComPtr aconteçam antes que CoUninitialize seja chamado.Portanto, um CComPtr não deve se tornar estático.