la réinitialisation de bold_ptr affecte shared_ptr?

11

Je n'ai pas l'habitude de l'utiliser weak_ptret 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_ptrsoit modifié / invalidé lorsque / un associé weak_ptrest 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.

dom_beau
la source
2
Je pense que votre implémentation a un bug. gcc produit les bons résultats
NathanOliver
1
Impossible de reproduire dans Visual Studio 2019 (v. 16.2.5)
Frodyne
1
Non, ce n'est certainement pas normal.
capricieuse
4
Dans le cas où cela -572662307 = 0xDDDDDDDDaiderait au débogage, qui est la façon dont msvc indique la mémoire de tas libérée
Eric

Réponses:

2

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.

dom_beau
la source
1
Pourriez-vous ajouter un lien vers le rapport de bogue dans votre réponse? De cette façon, toute personne ayant le même problème peut être référée au rapport de bogue pour son état.
Sander De Dycker
Je vais plutôt ajouter un commentaire une fois le cas résolu.
dom_beau
1
Oui, veuillez ajouter le lien - cela permettra aux lecteurs d'ajouter leurs propres remarques au rapport.
halfer
Je ne vois pas comment. Si vous atteignez le lien, vous avez besoin d'un compte Intel pour le voir ??? J'ai peut-être tort??? Dites-moi ... J'ai ouvert un ticket et il est dans mon compte.
dom_beau
Peut-être que vous pouvez atteindre la discussion que j'ai sur le forum: Forum du compilateur C ++
dom_beau
1

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:

int i = 1; cout << i << " " << ++i << endl;

Si la sortie est à la 2 2place de 1 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 de reset(). 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.

Swift - Friday Pie
la source
Il donne 1 2à la fois 64 bits et 32 bits , Debug et Release .
dom_beau
2
Le bogue est par _Ref_count_basedéfaut cTor qui est spécifié = default. Les deux membres _Uses = 1et _Weaks = 1sont définis sur 1et 0respectivement. Il semble que le cTor généré par défaut soit buggé. Voir le memorydossier ...
dom_beau
@dom_beau bien, ça vaut le coup d'oeil, on sait aussi que l'initialisation en C ++ est sérieusement Bonkers
Swift - Friday Pie