Je n'ai pas l'habitude de l'utiliser weak_ptr
et je suis confronté à une situation assez déroutante. J'utilise Intel XE 2019 Composer update 5 ( package 2019.5.281 ) en combinaison avec Visual Studio 2019 ver. 16.2.5 . Je compile en 64 bits. J'utilise le standard C ++ 17 .
Voici le code de ma solution de pointe:
#include <memory>
#include <iostream>
using namespace std;
int main( int argc, char* argv[] )
{
shared_ptr<int> sp = make_shared<int>( 42 );
cout << "*sp = " << *sp << endl;
weak_ptr<int> wp = sp;
cout << "*sp = " << *sp << ", *wp = " << *wp.lock() << endl;
wp.reset();
cout << "*sp = " << *sp << endl;
return 0;
}
La sortie que je m'attendais à avoir est:
*sp = 42
*sp = 42, *wp = 42
*sp = 42
... mais voici ce que j'ai obtenu:
*sp = 42
*sp = 42, *wp = 42
*sp = -572662307
Qu'est ce que passe? Est-il normal que le shared_ptr
soit modifié / invalidé lorsque / un associé weak_ptr
est réinitialisé? Je suis un peu confus quant aux résultats que j'ai obtenus. Pour dire la vérité, je ne m'attendais pas à ce résultat ...
EDIT 1
Bien que le bogue se produise dans la configuration 64 bits , il ne l'est pas en 32 bits . Dans cette configuration ultérieure, le résultat est ce qui est attendu.
EDIT 2
Le bogue se produit uniquement dans Debug . Lorsque je crée dans Release , j'obtiens le résultat attendu.
la source
-572662307 = 0xDDDDDDDD
aiderait au débogage, qui est la façon dont msvc indique la mémoire de tas libéréeRéponses:
Il semble que ce soit un vrai bug du côté Intel ICC; Je l'ai signalé.
Merci encore de m'avoir aidé à identifier ce problème.
la source
Cela ressemble à un bogue dans la bibliothèque de débogage, avec des valeurs sentinelles.Il est facile de vérifier, en utilisant la ligne que j'ai mentionnée:
Si la sortie est à la
2 2
place de1 2
, le compilateur n'est pas conforme et considère peut-être toujours un tel cas comme un UB. Les valeurs sentinelles peuvent être utilisées à tort dans ce cas avec l'appel dereset()
. La même chose se produit avec la suppression d'un objet créé en plaçant new dans un tampon statique préalloué, en mode débogage, il est remplacé par certaines implémentations avec des valeurs sentinelles.la source
1 2
à la fois 64 bits et 32 bits , Debug et Release ._Ref_count_base
défaut cTor qui est spécifié= default
. Les deux membres_Uses = 1
et_Weaks = 1
sont définis sur1
et0
respectivement. Il semble que le cTor généré par défaut soit buggé. Voir lememory
dossier ...