reset lemah_ptr mempengaruhi shared_ptr?

11

Saya tidak terlalu terbiasa menggunakan weak_ptrdan saya menghadapi situasi yang cukup membingungkan. Saya menggunakan Intel XE 2019 Composer pembaruan 5 ( paket 2019.5.281 ) dalam kombinasi dengan Visual Studio 2019 ver. 16.2.5 . Saya kompilasi dalam 64-bit. Saya menggunakan standar C ++ 17 .

Berikut adalah kode untuk solusi spike saya:

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

Output yang saya harapkan adalah:

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

... tapi inilah yang saya dapatkan:

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

Apa yang sedang terjadi? Apakah normal untuk shared_ptrdimodifikasi / tidak valid ketika / yang terkait weak_ptrdireset? Saya sedikit bingung dengan hasil yang saya peroleh. Sejujurnya saya tidak mengharapkan hasil ini ...

EDIT 1

Sementara bug terjadi dalam konfigurasi 64-bit , itu tidak dalam 32-bit . Dalam konfigurasi nanti ini, hasilnya adalah apa yang diharapkan.

EDIT 2

Bug hanya terjadi di Debug . Ketika saya membuat Rilis , saya mendapatkan hasil yang diharapkan.

dom_beau
sumber
2
Saya pikir implementasi Anda memiliki bug. gcc menghasilkan hasil yang benar
NathanOliver
1
Tidak dapat mereproduksi di Visual Studio 2019 (v. 16.2.5)
Frodyne
1
Tidak, ini jelas tidak normal.
aneh
4
Dalam hal ini membantu men-debug,, -572662307 = 0xDDDDDDDDyang merupakan cara msvc untuk menunjukkan memori tumpukan yang dibebaskan
Eric

Jawaban:

2

Tampaknya itu adalah bug nyata di sisi Intel ICC; Saya sudah melaporkannya.

Sekali lagi terima kasih telah membantu saya menunjukkan masalah ini.

dom_beau
sumber
1
Bisakah Anda menambahkan tautan ke laporan bug dalam jawaban Anda? Dengan begitu, siapa pun dengan masalah yang sama dapat dirujuk ke laporan bug untuk statusnya.
Sander De Dycker
Saya lebih suka menambahkan komentar setelah kasing diperbaiki.
dom_beau
1
Ya tolong tambahkan tautan - ini akan memungkinkan pembaca untuk menambahkan komentar mereka sendiri ke dalam laporan.
halfer
Tidak tahu caranya. Jika Anda mencapai tautan, Anda memerlukan akun Intel untuk melihatnya ??? Mungkin aku salah??? Katakan ... saya membuka tiket dan itu ada di akun saya.
dom_beau
Mungkin Anda dapat mencapai diskusi yang saya alami di forum: forum C ++ compiler
dom_beau
1

Sepertinya bug di perpustakaan debug, dengan nilai sentinel. Mudah untuk memeriksa, dengan menggunakan baris yang saya sebutkan:

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

Jika output 2 2bukan 1 2, maka kompiler tidak sesuai dan mungkin masih menganggap hal tersebut sebagai UB. Nilai sentinel dapat digunakan secara salah dalam hal ini dengan panggilan reset(). Hal yang sama terjadi dengan menghapus objek yang dibuat oleh penempatan baru dalam buffer statis yang telah dialokasikan, dalam mode debug itu akan ditimpa oleh beberapa implementasi dengan nilai-nilai sentinel.

Swift - Friday Pie
sumber
Ini memberikan 1 2baik dalam 64-bit dan 32-bit , Debug dan Rilis .
dom_beau
2
Bug ada dalam _Ref_count_basecTor default yang ditentukan = default. Dua anggota _Uses = 1dan _Weaks = 1diatur ke 1dan 0masing - masing. Tampaknya cTor yang dihasilkan default disadap. Lihat memoryfile ...
dom_beau
@dom_beau baik, layak laporan, kita juga tahu bahwa inisialisasi dalam C ++ adalah Serius Bonkers
Swift - Friday Pie