Não estou muito acostumado a usar weak_ptre estou enfrentando uma situação bastante confusa. Estou usando o Intel XE 2019 Composer atualização 5 ( pacote 2019.5.281 ) em combinação com o Visual Studio 2019 ver. 16.2.5 . Eu compilo em 64 bits. Eu uso o padrão C ++ 17 .

Aqui está o código para minha solução de 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;
}

A saída que eu esperava ter é:

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

... mas aqui está o que eu obtive:

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

O que está acontecendo? É normal shared_ptrque seja modificado / invalidado quando o / um associado weak_ptré redefinido? Estou um pouco confuso com os resultados que obtive. Para dizer a verdade, eu não esperava esse resultado ...

EDIT 1

Enquanto o erro ocorre na configuração de 64 bits , não ocorre em 32 bits . Nesta configuração posterior, o resultado é o que é esperado.

EDIT 2

O erro ocorre apenas na depuração . Quando crio no Release , obtenho o resultado esperado.

Parece que é um bug real no lado da Intel ICC; Eu relatei isso.

Obrigado novamente por me ajudar a identificar esse problema.

Parece um bug na biblioteca de depuração, com valores de sentinela. É fácil verificar, usando a linha que mencionei:

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

Se a saída for em 2 2vez de 1 2, o compilador não é compatível e, possivelmente, ainda considera esse caso um UB. Os valores do Sentinel podem ser usados ​​erroneamente nesse caso com a chamada de reset(). O mesmo ocorre com a exclusão do objeto criado pela colocação de novo no buffer estático pré-alocado, no modo de depuração ele é substituído por algumas implementações com valores sentinela.