Non sono molto abituato ad usare weak_ptre sto affrontando una situazione piuttosto confusa. Sto usando Intel XE 2019 Composer update 5 ( pacchetto 2019.5.281 ) in combinazione con Visual Studio 2019 ver. 16.2.5 . Compilo in 64 bit. Uso lo standard C ++ 17 .

Ecco il codice per la mia soluzione spike:

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

L'output che mi aspettavo di avere è:

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

... ma ecco cosa ho ottenuto:

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

Cosa sta succedendo? È normale shared_ptrche venga modificato / invalidato quando weak_ptrviene ripristinato / an associato ? Sono un po 'confuso riguardo ai risultati che ho ottenuto. A dire il vero non mi aspettavo questo risultato ...

MODIFICA 1

Mentre il bug si verifica nella configurazione a 64 bit , non nel 32 bit . In questa configurazione successiva, il risultato è quello che ci si aspetta.

MODIFICA 2

Il bug si verifica solo in Debug . Quando compilo in Release , ottengo il risultato atteso.

Sembra che sia un vero bug sul lato Intel ICC; L'ho segnalato.

Grazie ancora per avermi aiutato a individuare questo problema.

Sembra un bug nella libreria di debug, con valori sentinella. È facile da controllare, usando la linea che ho citato:

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

Se l'output è 2 2invece di 1 2, allora il compilatore non è conforme e probabilmente considera comunque un UB. I valori di Sentinel possono essere utilizzati erroneamente in questo caso con call of reset(). Una cosa simile accade quando si elimina un oggetto creato posizionando un nuovo all'interno di un buffer statico preallocato, in modalità debug viene sovrascritto da alcune implementazioni con valori sentinella.