👨‍👧‍👧 🙃 🥠 Perpustakaan Standar Hari Kematian 🙌 👨🏼‍🔬 👨🏼‍🔧

Suatu hari di Praha, komite standardisasi C ++ melakukan serangkaian survei tentang masalah mengubah ABI, dan akhirnya diputuskan untuk tidak mengubah apa pun di dalamnya. Tidak ada tepuk tangan di aula.
Saya pikir kami tidak sepenuhnya menyadari konsekuensi yang akan ditimbulkan oleh keputusan ini, dan saya tidak percaya bahwa, pada prinsipnya, hal itu dapat memengaruhi perkembangan bahasa secara positif.

Apa itu ABI?

ABI - seperangkat konvensi yang menentukan bagaimana program Anda direpresentasikan dalam bentuk biner, bagaimana nama dideklarasikan di dalamnya, markup kelas ditentukan, dan konvensi pemanggilan fungsi didefinisikan. Sebenarnya, ini semacam protokol biner, tetapi tidak diversi.
Agar tidak membingungkan Anda dalam terminologi, mari kita lihat contoh dari apa yang diperlukan oleh perubahan ABI dan penguraiannya dalam program:

Anda tidak dapat menggunakan simbol yang diekspor dalam versi baru dari perpustakaan Anda yang dikompilasi jika Anda melakukan salah satu dari yang berikut:

Menambahkan bidang baru ke kelas yang ada
Mengubah parameter templat dari kelas / fungsi, mengubah fungsi templat menjadi non-templat, atau sebaliknya, menambahkan templat variadik
Terapkan specifier sebaris untuk sesuatu
Menambahkan parameter default dalam deklarasi fungsi
Metode virtual baru diumumkan

Dan masih banyak lagi, tetapi contoh-contoh di atas adalah yang utama yang disebutkan oleh panitia, dan yang paling, berkat yang sebagian besar proposal dalam standar dihancurkan di tempat. Saya menghilangkan opsi untuk melanggar ABI, di mana kode sumber program juga rusak (misalnya, menghapus atau mengubah fungsi). Namun, ini tidak selalu benar. Misalnya, menghapus fungsi tidak selalu berarti melanggar kode sumber. std::stringIni memiliki operator konversi std::string_view, yang dengan senang hati akan saya singkirkan, dan meskipun menghapusnya akan merusak ABI, itu tidak akan menyebabkan masalah yang signifikan dalam kode sumber.

Kenapa kita harus hancurkan ABI

Pertama-tama, ada beberapa perubahan yang berguna dalam implementasi pustaka standar yang dapat Anda terapkan jika Anda melanggar ABI saat ini:

Buat wadah asosiatif (jauh) lebih cepat
Percepat pekerjaan Anda std::regex(Saat ini, lebih cepat untuk menjalankan PHP dan mencarinya dengan ekspresi reguler daripada menggunakan yang standar std::regex)
Beberapa perubahan std::string, std::vectorserta tata letak wadah lainnya
Unity of the class interface: saat ini, beberapa implementasinya sengaja tidak sesuai dengan antarmuka tunggal demi stabilitas

Lebih penting lagi, ada perubahan dalam desain perpustakaan yang tidak dapat dibuat tanpa menemui masalah keamanan ABI. Berikut adalah daftar yang tidak lengkap dari semua yang saat ini tidak layak karena alasan yang disebutkan di atas:

std::scoped_lock ditambahkan agar tidak merusak perubahan abi lock_guard
int128_t , intmax_t. , , , intmax_t deprecated
std::unique_ptr , zero-overhead
error_code - , ABI
status_code ABI
recursive_directory_iterator , ABI
<cstring> constexpr ( strlen) , ABI
UTF-8 std::regex — ABI
menambah dukungan reallocdan mengembalikan ukuran memori yang dialokasikan adalah gangguan ABI untuk pengalokasi polimorfik
Membuat Destructor Virtual Implisit untuk Jenis Polimorfik
tipe pengembalian y push_backdapat diubah jika ABI saat ini rusak
Secara umum, apakah kita benar-benar membutuhkan dan push_back, dan emplace_back?
std::shared_ptr juga menyebabkan kerusakan ABI
[[no_unique_address]] bisa jadi keluaran oleh kompiler jika kita tidak peduli tentang penghematan ABI saat ini

Dan daftarnya tidak berakhir di situ. Saya pikir WG21 harus mencoba untuk tetap memperbarui daftar hal-hal seperti itu. Tapi saya akan mencatat semua orang yang mengatakan "itu akan menghancurkan ABI", bersama saya di ruangan yang sama.

Apa lagi yang ingin kita ubah?

Saya tidak tahu Dan saya tidak tahu apa yang saya tidak tahu. Tetapi jika saya diminta menebak, saya akan mengatakan yang berikut:

C++23 ABI, - , ABI.
, , , , ABI
ABI,
, ABI
Tombstone ABI

ABI

Selama diskusi ABI terakhir, sejumlah survei dilakukan di Praha, yang, bagaimanapun, tidak memberi tahu kami apa pun. Tergantung pada apakah Anda seorang pesimis atau optimis, hasil saat ini dapat ditafsirkan oleh Anda secara berbeda.

Fakta-fakta kunci:

WG21 tidak ingin mendobrak ABI dalam 23
WG21 menganggap perlu untuk memutus ABI dalam versi C ++ yang akan datang (C ++ 26 atau lebih baru)
WG21 akan mengambil waktu untuk mempertimbangkan proposal yang melanggar ABI
WG21 tidak menjanjikan stabilitas abadi
WG21 menganggap penting untuk mempertahankan prioritas pada kinerja, bahkan merugikan stabilitas bahasa

Pernyataan-pernyataan ini memiliki banyak poin penting, tetapi tidak ada konsensus. Komite itu, anehnya, terbelah dua.

Meramal

Di mana versi C ++ menunggu perubahan

Kelemahan yang jelas dari semua jajak pendapat ini adalah bahwa kami belum memutuskan kapan tepatnya kami ingin mematahkan ABI.

di c ++ 23? Tidak, pasti belum.

dalam C ++ 26? Beberapa orang berniat untuk memilih, tetapi bagian lain cenderung memilih C ++ 41 atau saat mereka pensiun dan mereka tidak harus mendukung proyek mereka saat ini. Salah satu pertanyaan yang baru saja disebutkan C ++ - beberapa ; sangat nyaman!

Tidak ada alasan untuk percaya bahwa jika ABI tidak bisa dilanggar sekarang, maka bisa dilanggar nanti. Orang yang membutuhkan stabilitas beberapa tahun di belakang standar. Jadi jika kita tidak menghancurkannya sekarang, orang akan terus bergantung pada ABI yang tidak pernah dijanjikan, mungkin sepuluh atau bahkan dua puluh tahun lagi. Fakta sederhana bahwa kami melakukan survei ini pada akhirnya memilih untuk tidak melanggar ABI, menunjukkan bahwa seluruh ekosistem secara bertahap menjadi berbatu dan stagnan - setiap hari masalahnya semakin buruk dan berpotensi lebih mahal.

Saya tidak berpikir bahwa sesuatu akan berubah dalam survei yang dilakukan dalam tiga tahun. Ini seperti pemanasan global: semua orang setuju bahwa suatu hari kita perlu mengatasi masalah ini. Lalu mari kita larangan diesel pada tahun 2070?

Segala sesuatu yang tidak direncanakan akan dilakukan dalam lima tahun ke depan kemungkinan tidak akan pernah terjadi.

Tentang penawaran yang melanggar ABI

WG21 memilih untuk mencurahkan lebih banyak waktu untuk proposal yang melanggar ABI saat ini. Ini berarti beberapa hal:

Kami akan membuang lebih banyak waktu di salah satu ruang komite yang paling berisik untuk membahas masalah ini dan memberikan lebih sedikit pada proposal yang memiliki lebih banyak peluang adopsi, dan pada akhirnya kami akan menolaknya semua sama saja
Kami akan mencari alternatif yang tidak melanggar ABI (ini akan dibahas di bawah)
Perubahan parsial dalam ABI dapat diperkenalkan (lihat juga di bawah)

Kinerja lebih penting daripada stabilitas ABI

Ini seperti menanyakan apakah anak berusia lima tahun menginginkan permen. Tentu saja kami akan memilih pentingnya kinerja. Namun, saya khawatir beberapa orang masih menentang.

Sepertinya saya bahwa panitia pada saat yang sama ingin duduk di dua kursi sekaligus. Dan ini tidak mungkin:

Bryce Adelstein Lelbach @blebach
- Kinerja
- Stabilitas ABI
- Kemampuan untuk mengubah sesuatu

Pilih dua opsi dari yang diusulkan.

stabilitas bahasa dan ABI, tentu saja, saling bertabrakan, memaksa kami untuk mengajukan pertanyaan mendasar - Apa itu C ++ dan apa perpustakaan standarnya?

Biasanya dalam kasus ini, istilah “kinerja”, “ abstraksi nol biaya ”, “ jangan bayar untuk apa yang tidak Anda gunakan ” diingat . Dan stabilitas ABI berdiri di atas semua ini.

Konsekuensi yang jauh jangkauannya

Saya sangat yakin bahwa keputusan untuk tidak menghancurkan ABI di tahun ke-23 adalah kesalahan terbesar yang pernah dilakukan komite. Dan saya tahu bahwa beberapa orang percaya sebaliknya. Tapi inilah yang mungkin terjadi segera:

Mimpi buruk belajar

Mari jujur. Semua program yang bergantung pada ABI cenderung melanggar prinsip-prinsip ODR di suatu tempat atau menggunakan bendera yang tidak kompatibel, yang, untungnya, masih berfungsi.

Program-program baru harus dikompilasi dari kode sumber, kita membutuhkan alat yang dibangun di atas perakitan dari sumber, dan bukan koleksi perpustakaan yang kita dapatkan dari suatu tempat dan entah bagaimana dimasukkan ke dalam proyek.

Ya, membangun dari sumber adalah sesuatu yang tidak mudah dicapai. Tetapi kita perlu mendorong pendekatan ini pada produk, secara teratur memperbarui kompiler sehingga orang mendapat manfaat dari fitur yang baru diperkenalkan sebulan setelah rilis, dan tidak sepuluh tahun kemudian. Solusi yang tepat, andal, terukur, dan dapat direproduksi, perpustakaan sumber terbuka, dan sistem ketergantungan perlu didorong.

Menolak untuk melanggar ABI, panitia secara terbuka menyatakan bahwa mereka akan mendukung program yang ditulis dengan buruk sepanjang keberadaan mereka. Bahkan jika Anda tidak menautkan ke perpustakaan yang diperoleh melalui apt-install (yang sebenarnya ditujukan untuk sistem), akan ada orang lain, karena panitia memberi mereka berkah.

Ini adalah langkah mundur yang sangat besar. Bagaimana kita bisa mengajarkan orang lain praktik bahasa yang baik jika kita tidak memiliki insentif untuk melakukan ini?

Kehilangan minat pada perpustakaan standar

Perkiraan kerugian dalam kinerja perpustakaan karena keengganan kami untuk melanggar ABI diperkirakan 5-10%. Jumlah ini hanya akan bertambah seiring waktu. Mari kita lihat contoh-contohnya:

Jika Anda adalah perusahaan besar, Anda dapat membeli sendiri pusat data baru atau membayar tim pemrogram yang akan mendukung perpustakaan mereka sendiri
, 5% ,
, 5-10% , VR-
, —

Saya pikir, di sini, mau tidak mau, muncul pertanyaan antara: "Saya pasti harus menggunakan C ++ dan perpustakaan standarnya!" dan “Mungkin aku seharusnya tidak menggunakan perpustakaan standar? Atau mungkin saya seharusnya tidak menggunakan C ++ pada prinsipnya? Mungkin .NET, julia atau Rust akan menjadi solusi yang lebih baik? " Tentu saja, ada banyak faktor yang mempengaruhi jawabannya, tetapi kita melihat apa yang terjadi baru-baru ini.

Banyak pengembang game sangat skeptis terhadap pustaka standar. Mereka lebih suka mengembangkan alternatif mereka sendiri, seperti EASTL , daripada mengambil keuntungan dari STL. Facebook memiliki kebodohan , Google memiliki abseil dan sebagainya.

Ini seperti bola salju. Jika orang tidak menggunakan perpustakaan standar, mereka tidak tertarik untuk memperbaikinya. Kinerja adalah faktor kunci yang membuat perpustakaan tetap bertahan. Tanpa jaminan kinerja, lebih sedikit upaya akan dilakukan untuk pengembangannya.

>> Jonathan Müller @foonathan
Apa gunanya menggunakan kontainer dari perpustakaan standar jika mereka tidak memberikan kinerja yang lebih baik?

Titus Winters @TitusWinters
Mungkin karena mereka biasa dan mudah diakses? (dua fakta ini tidak berarti hal yang sama).
Memilih untuk melestarikan ABI seperti mengatakan bahwa perpustakaan standar harus berusaha keras untuk menjadi McDonald's - ia juga ada di mana-mana, ia stabil dan secara teknis menyelesaikan tugas-tugasnya.

Bagaimana komite dapat mempertimbangkan proposal yang melanggar ABI?

Beberapa opsi ditawarkan sebagai penghilang rasa sakit yang disebabkan oleh ketidakmampuan untuk menerima penawaran jika mereka melanggar ABI:

Menambahkan Nama Baru

Ini adalah solusi pertama dan jelas. Jika kita tidak bisa berubah std::unordered_map, bisakah kita tambahkan saja std::fast_map? Ada beberapa alasan mengapa ini buruk. Menambahkan jenis ke perpustakaan standar itu mahal, baik dari segi biaya dukungan dan dalam hal pendidikan. Setelah pengenalan kelas baru, ribuan artikel akan muncul, menjelaskan wadah mana yang harus digunakan. Misalnya, haruskah saya menggunakan std::scoped_lockatau std::lock_guard? Saya tidak punya ide! Saya perlu google setiap waktu. Ada juga masalah bahwa nama baik berakhir cepat atau lambat. Kami juga mendapatkan beberapa overhead selama eksekusi program, karena semua kontainer harus secara konstan dikonversi satu sama lain, menjadi sulit untuk mengontrol sejumlah besar konversi yang berlebihan di kelas, dll.

Ini ironis, tetapi orang-orang yang mendukung solusi di atas juga dapat berpendapat bahwa bahasa C ++ terlalu rumit. Menambahkan duplikat ke perpustakaan pasti tidak akan membuatnya lebih mudah.

Tetapi kami dapat menerima tawaran ini sebagai standar!

Beberapa pengembang perpustakaan mengklaim bahwa tawaran mereka ditolak karena pelanggaran ABI, meskipun mereka sebenarnya tidak melanggar apa pun, atau mereka dapat diubah untuk menghindari kegagalan ABI.

Sebagai orang yang sinis, agak sulit bagi saya untuk percaya. Faktanya adalah bahwa sebelum tidak ada proposal seperti itu, dan skenario di mana mereka dapat diterapkan sangat terbatas. ABI Review Group (ARG) dapat membantu dalam hal ini, tetapi mereka cenderung untuk merekomendasikan nama lain untuk kelas / fungsi lagi.

Pelanggaran Abi Sebagian

Gagasan utamanya bukan untuk memecah seluruh ABI, tetapi hanya mengubahnya untuk kelas atau fungsi tertentu. Masalah dengan pendekatan ini adalah bahwa alih-alih kesalahan pada tahap menghubungkan, kita akan melihat masalah sudah selama peluncuran program, dan itu akan menyenangkan untuk mengejutkan kita. Komite sudah mencoba pendekatan ini di C ++ 11 ketika itu mengubah markup std::string. Tidak ada yang baik dari itu. Semuanya begitu buruk sehingga fakta ini masih digunakan sebagai argumen untuk mempertahankan ABI saat ini.

Tingkat indeksasi lainnya

Sebuah solusi untuk beberapa masalah dengan ABI adalah kemampuan untuk mengakses data kelas melalui sebuah pointer, maka markup kelas akan menjadi pointer itu saja. Idenya sangat dekat dengan idiom PIMPL , yang secara aktif digunakan dalam Qt karena ABI-nya. Ya, itu akan menyelesaikan masalah dengan anggota kelas, tetapi apa yang harus dilakukan dengan metode virtual?

Mempertimbangkan masalah dari sudut pandang yang lebih kritis, kita berbicara tentang menambahkan tingkat tipuan lainnya (indeks dengan pointer) dan alokasi memori tambahan dalam tumpukan untuk semua yang terlampir dalam kerangka ABI. Dalam STL, pada kenyataannya, semuanya tertutup dalam kerangka kerja ini karena itu adalah kumpulan kelas umum.

Akibatnya, harga dari pendekatan ini akan sangat besar.

Sebagai solusi untuk masalah ini, sudah ada beberapa proposal dalam standar. Beberapa dari mereka ingin menjadikan PIMPL salah satu fitur bahasa, sehingga Anda dapat memilih antara stabilitas ABI dan kinerja tinggi.

Namun ironisnya, tetapi untuk mengubah tipe perpustakaan menjadi tipe PIPML, kita perlu ... memecah ABI.

Pasang kembali semua kode setiap tiga tahun

Pikiranku keras-keras.

Semua penawaran saat ini dalam standar harus dihancurkan

Secara paradoks, C ++ tidak pernah semeriah sekarang. Di Praha, 250 orang mengerjakan banyak hal untuknya, termasuk:

Numerik
Aljabar linier
Audio
Unicode
I / O tidak sinkron
Grafik 2D dan 3D
Banyak fitur lainnya

Semua proposal ini disatukan oleh satu fakta umum - mereka jauh lebih opsional dibandingkan dengan apa yang kita miliki dalam standar saat ini. Orang-orang hanya mencoba untuk membakukan hal-hal dari bidang penelitian dan pekerjaan mereka, atau apa yang terus berkembang dan berubah.
Secara khusus, algoritma Unicode sangat tidak stabil dan berubah dengan cepat dari waktu ke waktu.

Dan kemudian, horor seperti jaringan menjulang di cakrawala . Sangat, sangat tidak bertanggung jawab untuk mencoba membakukan apa pun yang dapat menyebabkan masalah keamanan, dan pada saat yang sama tidak dapat mengubahnya nanti (ingat tentang ABI).

Karena C ++ memutuskan untuk membuatnya stabil, semua saran ini harus dihancurkan dan dibakar. Saya tidak ingin dihancurkan, tetapi ini harus dilakukan.

Tetapi mereka masih tidak akan melakukannya.

Dalam kasus terbaik, kami tidak akan membuat kesalahan dan menstandarkan keadaan saat ini di salah satu versi baru C ++, dan kemudian membiarkan semuanya terurai perlahan, karena tidak mungkin untuk memperbaikinya (Dalam kasus Networking TS, kami tampaknya tidak dapat mengubah apa pun, oleh karena itu kita harus membakukan apa yang ada sepuluh tahun yang lalu, maka tentu saja perpustakaan masih dapat ditingkatkan secara signifikan, tetapi mari kita tinggalkan cerita ini untuk lain waktu).

Tapi tentu saja, kita akan membuat banyak kesalahan.

>> Ólafur Waage @olafurw
( , )

, !

. , ( : , , )?

Hyrum Wright @hyrumwright
, , . — , .

Beberapa kesalahan dilakukan dengan sengaja, karena merupakan trade-off, sementara yang lain tidak diperhatikan selama bertahun-tahun.

Waktu berlalu, tetapi perpustakaan standar tidak bergerak. Trade off yang sebelumnya secara bertahap mulai mengganggu kita, dan kemudian menjadi "hambatan" nyata dalam kode yang ada.

Beberapa hal benar-benar mustahil untuk diubah, karena mereka tertanam dalam API. Kita semua memiliki gagasan tentang betapa sulitnya mengubah API yang ada. Tetapi bagian dari kode masih dapat diperbaiki dan ditingkatkan jika kita dapat memecahkan ABI.

C ++ masih akan bertahan dalam 40 tahun ke depan. Jika kita tidak dapat menyadari perlunya mengubahnya dengan cara yang tidak dapat diprediksi setiap saat, maka satu-satunya langkah yang tepat adalah dengan tidak memainkan permainan ini secara prinsip.

Semua orang tahu bahwa wadah asosiatif standar telah relevan untuk digunakan selama kurang dari sepuluh tahun. Tetapi mengapa kita berpikir bahwa proposal yang lebih besar dalam standar akan lebih berhasil?

Tawaran Anda ke standar akan dihancurkan, tawaran saya akan dihancurkan dengan cara yang sama.

Dapatkah komite pada prinsipnya menghancurkan ABI?

Banyak yang yakin bahwa panitia pada prinsipnya tidak dapat membuat keputusan seperti itu, karena dengan begitu pengembang perpustakaan akan mengabaikannya. Semua ini mirip dengan gulat lengan, di mana panitia memutuskan untuk tidak bermain.

Tetapi kenyataannya adalah bahwa pengembang produk apa pun memiliki pengguna sendiri. Pengguna adalah mereka yang pertama-tama perlu memahami apa trade-off yang dikenakan pada mereka.

Banyak orang mengandalkan ABI secara tidak sengaja, tanpa membuat keputusan yang tepat. Banyak orang juga mengandalkan stabilitas karena, tentu saja, semua orang ingin bergantung padanya. Tetapi seperti hal lain, stabilitas memiliki harga, dan sekarang seluruh ekosistem C ++ membayar untuk itu.

Perpustakaan Standar Hari Kematian