schwaches_ptr-Reset wirkt sich auf shared_ptr aus?

11

Ich bin nicht sehr daran gewöhnt weak_ptrund stehe vor einer ziemlich verwirrenden Situation. Ich verwende Intel XE 2019 Composer Update 5 ( Paket 2019.5.281 ) in Kombination mit Visual Studio 2019 ver. 16.2.5 . Ich kompiliere in 64-Bit. Ich benutze das Standard C ++ 17 .

Hier ist der Code für meine Spike-Lösung:

#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;
}

Die Ausgabe, die ich erwartet hatte, ist:

*sp = 42
*sp = 42, *wp = 42
*sp = 42

... aber hier ist was ich erhalten habe:

*sp = 42
*sp = 42, *wp = 42
*sp = -572662307

Was passiert gerade? Ist es normal, dass das shared_ptrgeändert / ungültig gemacht wird, wenn das / ein zugeordnetes weak_ptrzurückgesetzt wird? Ich bin etwas verwirrt über die Ergebnisse, die ich erzielt habe. Um die Wahrheit zu sagen, ich habe dieses Ergebnis nicht erwartet ...

BEARBEITEN 1

Während der Fehler in der 64-Bit- Konfiguration auftritt , tritt er nicht in der 32-Bit - Konfiguration auf . In dieser späteren Konfiguration ist das Ergebnis das, was erwartet wird.

BEARBEITEN 2

Der Fehler tritt nur beim Debuggen auf . Wenn ich Release einbaue , erhalte ich das erwartete Ergebnis.

dom_beau
quelle
2
Ich denke, Ihre Implementierung hat einen Fehler. gcc liefert die richtigen Ergebnisse
NathanOliver
1
Kann in Visual Studio 2019 (
Version 16.2.5
1
Nein, das ist definitiv nicht normal.
freakish
4
Für den Fall, dass es beim Debuggen hilft. -572662307 = 0xDDDDDDDDDies ist die Methode von msvc, um den freigegebenen Heapspeicher anzuzeigen
Eric

Antworten:

2

Es scheint, dass es sich um einen echten Fehler auf der Intel ICC-Seite handelt. Ich habe es gemeldet.

Nochmals vielen Dank, dass Sie mir geholfen haben, dieses Problem zu lokalisieren.

dom_beau
quelle
1
Könnten Sie in Ihrer Antwort einen Link zum Fehlerbericht hinzufügen? Auf diese Weise kann jeder mit demselben Problem auf den Fehlerbericht für seinen Status verwiesen werden.
Sander De Dycker
Ich werde lieber einen Kommentar hinzufügen, sobald der Fall behoben ist.
dom_beau
1
Ja, bitte fügen Sie den Link hinzu. Auf diese Weise können die Leser dem Bericht ihre eigenen Anmerkungen hinzufügen.
halfer
Ich verstehe nicht wie. Wenn Sie den Link erreichen, benötigen Sie ein Intel-Konto, um ihn zu sehen ??? Vielleicht bin ich falsch??? Sag mir ... Ich habe ein Ticket geöffnet und es ist auf meinem Konto.
dom_beau
Vielleicht können Sie die Diskussion erreichen, die ich im Forum habe: C ++ - Compiler-Forum
dom_beau
1

Es sieht aus wie ein Fehler in der Debug-Bibliothek mit Sentinel-Werten. Es ist einfach zu überprüfen, indem Sie die Zeile verwenden, die ich erwähnt habe:

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

Wenn die Ausgabe 2 2anstelle von erfolgt 1 2, ist der Compiler nicht kompatibel und betrachtet einen solchen Fall möglicherweise immer noch als UB. Sentinel-Werte können in diesem Fall bei Aufruf von fälschlicherweise verwendet werden reset(). Ähnliches gilt für das Löschen von Objekten, die durch Platzieren eines neuen Objekts im vorab zugewiesenen statischen Puffer erstellt wurden. Im Debug-Modus wird es von einigen Implementierungen mit Sentinel-Werten überschrieben.

Swift - Friday Pie
quelle
Es gibt 1 2sowohl 64-Bit als auch 32-Bit , Debug und Release .
dom_beau
2
Der Fehler ist im _Ref_count_baseStandard-cTor angegeben = default. Die beiden Mitglieder _Uses = 1und _Weaks = 1sind auf 1und 0sind. Es scheint, dass der standardmäßig generierte cTor fehlerhaft ist. Siehe die memoryDatei ...
dom_beau
@dom_beau gut, es ist einen Bericht wert, auch wir wissen, dass die Initialisierung in C ++ Seriously Bonkers
Swift - Friday Pie