Я не дуже звик користуватися weak_ptrі зіткнувся з досить заплутаною ситуацією. Я використовую Intel XE 2019 Composer update 5 ( пакет 2019.5.281 ) у поєднанні з Visual Studio 2019 ver. 16.2.5 . Я компілюю в 64-розрядні. Я використовую стандартний C ++ 17 .

Ось код мого рішення з шипом:

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

Вихід, який я очікував, - це:

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

... але ось що я отримав:

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

Що відбувається далі? Чи нормально shared_ptrзмінити / визнати недійсними під час weak_ptrскидання / асоційованого ? Я трохи розгублений у отриманих результатах. По правді кажучи, я не очікував цього результату ...

РЕДАКТ 1

Хоча помилка виникає в 64-розрядної конфігурації, вона не є в 32-бітовій . У цій більш пізній конфігурації результат - це те, що очікується.

EDIT 2

Помилка трапляється лише в Налагодження . Коли я будую Release , я отримую очікуваний результат.

Здається, це справжня помилка на стороні Intel ICC; Я повідомив про це.

Ще раз дякую, що допомогли мені вирішити цю проблему.

Це схоже на помилку в бібліотеці налагодження із значеннями дозорних даних. Це легко перевірити, за допомогою вказаного рядка:

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

Якщо вивід є 2 2замість 1 2, компілятор не сумісний і, можливо, все ще вважає такий випадок UB. Значення Sentinel можуть використовуватися помилково в цьому випадку з викликом reset(). Подібне відбувається і з видаленням об'єкта, створеного шляхом розміщення нового в попередньо виділеному статичному буфері, в режимі налагодження він перезаписується деякими реалізаціями зі значеннями дозорних.