2016-02-04 5 views
0

Ceci est probablement de base, mais cela fait longtemps que je l'ai utilisé. Je l'ai vu des exemples comme chacun des éléments suivants:Quelle est la bonne manipulation de IErrorInfo version

IErrorInfo *pError; 
HRESULT hrError = ::GetErrorInfo(NULL, &pError); 
//more code here    
if (SUCCEEDED(hrError) && pError) { 
    //more code here    
    pError->Release(); 
} 

puis ailleurs

IErrorInfo *pError; 
HRESULT hrError = ::GetErrorInfo(NULL, &pError); 
//more code here    
if (SUCCEEDED(hrError) && pError) { 
    //more code here    
} 
pError->Release(); 

Lequel de ces est la bonne façon d'utiliser le Release() ici? Est-ce que ça importe; et si oui, pourquoi?

+0

Ils ont tous deux tort. Ce genre de style de codage «ne me dis pas que j'ai un bug de pointeur nul» est omniprésent et ne fait que créer des rapports de bugs «ça ne marche pas». Vous ne pouvez pas éviter de trouver le bogue dans le deuxième extrait. –

+0

@HansPassant peut-être cette partie non déclarée de ce qui m'a dérangé au sujet du premier exemple, maintenant quelle serait la meilleure façon de le faire? –

+0

Il suffit de supprimer '&& pError' –

Répondre

1

La première utilisation est correcte, bien que dans le "plus de code ici", vous devez veiller à ne pas déclencher une exception.

Il serait préférable d'utiliser un pointeur intelligent au lieu de IErrorInfo *, qui appellera automatiquement Release() en cas de sortie du champ d'application. Alors votre code ne fuira pas dans le cas du "plus de code ici" en lançant une exception.

Le second est faux, car si pError est nul ou indéterminé, le déréférencement provoque un comportement indéfini.

+0

C'est ce que je pensais moi-même mais comme je l'ai indiqué je n'ai pas fait de trucs COM C++ depuis un moment ... –