Suatu hari ada pertemuan Komite untuk Standardisasi bahasa pemrograman C ++ di Belfast. Sekitar 400 komentar tentang C ++ 20 terbang dari perwakilan negara ke komite, dan setengah dari mereka berhasil mengatasinya.
Di bawah potongan Anda sedang menunggu hasil diskusi dari komentar Rusia (ya, komentar ANDA di C ++ 20), beberapa komentar dari negara lain, dan tentu saja C ++ 23 baru yang sesuai (Pelaksana!).
Semua masalah dengan C ++ yang disebutkan orang di situs
stdcpp.ru , di chat
@ProCxx , di kantor di Yandex.Taxi, atau secara langsung di konferensi, kami meresmikan dalam bentuk komentar di C ++ 20. Jadi apa yang terjadi ...
std :: atomic <int> a {}; dan std :: atomic <int> b;
Ini mungkin tampak aneh, tetapi variabel
a dan
b tidak diinisialisasi ke 0. Untuk menginisialisasi variabel atom menjadi nol, perlu untuk menulis std :: atomic <int> dengan {0};
Perilaku ini benar-benar tidak terlihat, dan banyak pengembang membakar diri mereka sendiri. Komite menerima komentar kami pada standar, dan di C ++ 20, konstruktor default untuk std :: atomic_flag dan std :: atomic akan menginisialisasi variabel dalam
keadaan yang jelas dan T (), masing-masing.
std :: mencuci
Dimulai dengan C ++ 17, standar ini memiliki fungsi menakutkan std :: launder. Orang-orang dari panitia berpikir bahwa pengembang perpustakaan standar dan pengguna biasa akan mengetahui cara menghadapinya.
Dalam praktiknya, ternyata dalam beberapa kasus fungsi ini tidak dapat digunakan. Sangat tidak jelas bahwa pada prinsipnya diperlukan:
struct C { const int c; }; std::vector<C> v = {C{1}}; v.pop_back(); v.push_back(C{2}); assert(v.back().c == 2);
Jika Anda benar-benar mengikuti huruf standar, maka tergantung pada implementasi pustaka standar, fitur-fitur dari kompiler dan fase bulan, pernyataan mungkin lulus atau gagal.
Ketika membahas masalah, ternyata optimisasi, yang oleh karenanya standar menggambarkan perilaku aneh tersebut, hanya diterapkan di salah satu penyusun dan tidak membawa peningkatan kinerja yang nyata.
Jadi mulai dengan C ++ 20, Anda dapat menyimpan struktur dengan tautan dan bidang konstan dengan aman di std :: opsional, std :: varian, std :: vector, std :: deque, dll. Sekarang penempatan yang baru secara otomatis menerapkan bagian dari logika std: : mencuci.
* ini dalam konstruktor
Ini adalah salah satu komentar di mana kegagalan menunggu kami:
struct C { C(C&& other) noexcept : initial_(other.initial_) , secondary_(other.initial_)
Menurut aturan saat ini, sejalan dengan
O_O, kompiler memiliki hak untuk menganggap bahwa & lainnya == ini dan, karenanya, satu baris di atas, kami menulis ulang nilai other.initial_ dan perlu dibaca kembali.
Dengan kata lain, kompiler memiliki hak untuk berasumsi bahwa kelas yang belum dibuat alias dengan parameter dari mana objek dibangun, dan karena ini dapat menghasilkan kode yang tidak optimal.
Beberapa kompiler (misalnya, GCC), percaya bahwa pengguna tidak menulis aib seperti itu, dan percaya bahwa pengabaian tidak mungkin.
Panitia menolak pernyataan kami, “Anggap saja aliasing tidak mungkin”. Ternyata, beberapa basis kode memiliki retas menakutkan di mana & lainnya == ini, dan orang-orang belum siap untuk mengucapkan selamat tinggal kepada mereka.
operator <=> dan pemrograman tertanam
Agar operator pesawat ruang angkasa bekerja, Anda memerlukan file header <compare>. Namun, itu tidak ada dalam daftar file header yang tersedia di platform apa pun (pada apa yang disebut
implementasi berdiri bebas dari perpustakaan standar yang dapat digunakan pada besi apa pun).
Sekarang ada di daftar :)
Sisanya
Menurut komentar kami yang lain, putusan “Tidak dalam C ++ 20” dikeluarkan:
* Kami ingin __func__ digunakan di constexpr.
* Kami ingin konsep tersebut tidak menggunakan tipe tidak lengkap, karena jika tidak, Anda akan mendapatkan beberapa pelanggaran ODR. Tetapi komentar tersebut memiliki efek positif yang tidak terduga: kompiler sekarang mengeluarkan peringatan jika Anda menggunakan tipe yang tidak lengkap dalam membutuhkan.
* Kami ingin memperbaiki operator penugasan untuk std :: string sehingga kekacauan seperti itu tidak akan terjadi:
basic_string::operator=(charT c): double d = 3.14; std::string s; s = d;
Panitia menyarankan untuk menulis makalah terpisah dan memperbaikinya setelah C ++ 20.
* Kami ingin mematikan penugasan baris sementara di std :: string_view:
std::string foo(); std::string_view sv; sv = foo();
Hasilnya sama dengan komentar sebelumnya: panitia menyarankan untuk menulis makalah terpisah dan mengoreksi ini setelah C ++ 20.
* Kami meminta agar kode ini dikompilasi:
#include <type_traits> template <typename... Xs> auto f (Xs...) -> std::invoke_result_t<Xs...>;
Kami diberitahu bahwa semuanya rumit, praktis tidak ada kesempatan untuk memperbaiki C ++ 20.
Komentar dari negara lain
Perubahan signifikan: menambahkan konstruktor untuk std :: span dari jenis yang memenuhi konsep rentang :: contiguous_range. Jadi sekarang span dapat secara implisit dibuat dari std :: vector dan std :: string. Kami juga menambahkan konstruktor std :: string_view dari dua iterator yang memenuhi konsep rentang :: contiguous_iterator.
Suntingan menyenangkan menunggu <compare>. Selama tiga tahun terakhir, operator <=> telah banyak berubah. Dia tidak lagi terlibat dalam perbandingan untuk kesetaraan, dan karenanya, sepertiga dari konten <compare> tidak lagi diperlukan. Beberapa negara telah memperhatikan hal ini - mereka telah mengurangi standarnya.
Perubahan besar menyelinap ke parameter template non-tipe. Dalam C ++ 20, akan dimungkinkan untuk melewati
hampir semua kelas (lihat P1907) dengan destruktor constexpr dan anggota publik sebagai parameter templat, bahkan jika kelas tersebut berisi tipe atau tautan titik-mengambang.
Kami juga menambahkan const yang hilang ke berbagai bagian standar, mengubah nama dan urutan argumen dari beberapa fungsi baru ke C ++ 20. Ada juga banyak suntingan untuk konsep dan rentang, singkatan dari teks standar dan hal-hal kecil lainnya.
Bilangan TS
ZaMaZaN4iK dan
saya dapat membangkitkan komite dengan dokumen C ++ Numerics Work In Progress. Sekarang ada rencana Napoleonic untuk C ++ 23 untuk memberikan pengguna satu set nomor baru (wide_integer, integer, rasional), bersama dengan metode tingkat rendah tambahan untuk bekerja dengan luapan dan alias yang nyaman.
Saya diberitahu untuk menyiapkan presentasi untuk pertemuan berikutnya dengan pengantar ide-ide untuk seluruh komite.
Pelaksana
Pelaksana adalah salah satu prioritas C ++ 23. Mereka diperlukan untuk pemrograman reaktif, untuk pemrograman asinkron (jaringan, disk, proses ...), mereka adalah dasar untuk penjadwalan coroutine dan harus menyediakan antarmuka tunggal untuk perpustakaan pihak ketiga.
Pada saat yang sama, pelaksana harus mengoptimalkan algoritma untuk implementasi internal mereka. Misalnya, untuk kode:
template <std::input_range Range> void MySort(Range& data) { namespace stdr = std::ranges; std::sort(GetGlobalExecutor(), stdr::begin(data), stdr::end(data), 42); }
fungsi GetGlobalExecutor () dapat mengembalikan:
* pelaksana single-threaded - itu harus mengeksekusi std :: sort biasa pada utasnya;
* pelaksana multithreaded - harus melakukan penyortiran paralel;
* Pelaksana GPU - harus memindahkan data ke memori kartu video, mengurutkannya di sana dan mengembalikan data;
* Pelaksana NUMA - ...
* ...
Sejauh ini, untuk mengimplementasikan fungsi seperti itu, Anda perlu melakukan Customization Point Objects (CPO) yang menakutkan, ubah setiap algoritma menjadi mereka. Panitia tidak menyukainya ...
Tapi setidaknya mereka
menyetujui P0443 - antarmuka dasar. Semua kalimat selanjutnya untuk pelaksana harus ditulis dalam bentuk patch untuk P0443.
Alih-alih total
Sekarang kita dipisahkan dari C ++ 20 hanya dengan satu pertemuan komite. Hanya sedikit yang tersisa ...
Nah, semua orang yang ingin mengobrol dengan perwakilan komite secara langsung - lihat mitaps dan konferensi C ++
(*) :
*
Corehard di Minsk*
C ++ Siberia 2020*
C ++ Rusia 2020*
St. Petersburg C ++ Kelompok Pengguna*
C ++ Rapat 2019 di Moskow(*) Life hack: Anda tidak perlu membayar tiket konferensi jika Anda seorang pembicara.