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.
-572662307 = 0xDDDDDDDD
aiderait au débogage, qui est la façon dont msvc indique la mémoire de tas libérée