Est-ce un bogue d'auto-affectation dans ATL :: CComVariant?

Question

ATL::CComVariant a a handful of assignment operators. Ce que je vois dans la mise en œuvre est que dans les opérateurs d'affectation acceptant LPCOLESTR, IUnknown* ou IDispatch* la première action est d'appeler Clear().

Si l'opérateur a invoqué de telle sorte qu'une variable membre du même objet est passé

CComVariant variant; 
variant = L"string"; 
variant = variant.bstrVal; 

(il sont des moyens moins muets qui auront le même effet) Clear() va libérer l'objet encapsulé et toutes les actions ultérieures sur le pointeur qui se balance maintenant entraîneront un comportement indéfini.

Suis-je correct ou ai-je mal compris quelque chose?

Answer 1

C'est un bug. Malheureusement, ATL en possède encore beaucoup plus que ce que j'ai pu traiter dans n'importe quelle autre bibliothèque ayant une portée similaire.

Answer 2

variant = variant.bstrVal; 

Comme CComVariant instance gère le pointeur de la chaîne, la logique attendue avec une telle cession est cette instance de classe fait double emploi avec la chaîne et initialise membres internes (type et pointeur de la chaîne). Les valeurs/ressources actuellement possédées sont éliminées.

Si nous transmettons un pointeur propriétaire en tant qu'argument, nous souhaitons être sûrs que la valeur est dupliquée avant que la valeur de membre ne soit libérée. Ou, en ce que la méthode détecte correctement le cas "même pointeur" et ignore l'assignation. À partir de Visual Studio 2015 Update 3, ATL fait exactement cela: il détecte la même attribution de pointeur et retourne immédiatement l'allocation de la partie allocation/libération. C'est-à-dire que la mise en œuvre d'ATL est précise et gère bien cela.