No estoy muy acostumbrado a usar weak_ptry me enfrento a una situación bastante confusa. Estoy usando Intel XE 2019 Composer actualización 5 ( paquete 2019.5.281 ) en combinación con Visual Studio 2019 ver. 16.2.5 . Compilo en 64 bits. Yo uso el estándar C ++ 17 .

Aquí está el código para mi solución de pico:

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

El resultado que esperaba tener es:

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

... pero esto es lo que obtuve:

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

¿Que está pasando? ¿Es normal shared_ptrque se modifique / invalide cuando weak_ptrse reinicia el / an asociado ? Estoy un poco confundido acerca de los resultados que obtuve. A decir verdad, no esperaba este resultado ...

EDITAR 1

Si bien el error ocurre en la configuración de 64 bits , no ocurre en 32 bits . En esta configuración posterior, el resultado es lo que se espera.

EDITAR 2

El error ocurre solo en Debug . Cuando construyo en Release , obtengo el resultado esperado.

Parece que es un error real en el lado de Intel ICC; Lo he reportado.

Gracias de nuevo por ayudarme a señalar este problema.

Parece un error en la biblioteca de depuración, con valores centinela. Es fácil de verificar, usando la línea que mencioné:

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

Si la salida es en 2 2lugar de 1 2, entonces el compilador no es compatible y posiblemente todavía considere ese caso como un UB. Los valores centinela pueden usarse erróneamente en este caso con call of reset(). Algo similar ocurre con la eliminación de objetos creados mediante la colocación de nuevos en el búfer estático preasignado, en el modo de depuración se sobrescribe con algunas implementaciones con valores centinela.