Bahasa pengaturcaraan C++ kini berada di persimpangan jalan ketika komuniti bergelut dengan soalan asas mengenai keselamatan, keserasian ke belakang, dan hala tuju masa depan bahasa tersebut. Walaupun C++26 memperkenalkan tingkah laku yang salah untuk menangani pembacaan pemboleh ubah yang tidak diinisialisasi, kontroversi yang lebih besar telah muncul mengenai pengendalian jawatankuasa terhadap cadangan keselamatan yang komprehensif.
C++26 Tingkah Laku Bermasalah berbanding Alternatif
- Status Quo ( C++23 ): Pembacaan tidak diinisialisasi menyebabkan tingkah laku tidak ditentukan, diagnostik tidak boleh dipercayai
- Inisialisasi Sifar: Boleh diramal tetapi berpotensi menyembunyikan pepijat, membatalkan alat diagnostik
- Tingkah Laku Bermasalah ( C++26 ): Tingkah laku salah yang ditakrifkan dengan baik, mengekalkan keupayaan diagnostik
- Mekanisme Opt-out: Atribut [[indeterminate]] untuk kod kritikal prestasi
Jawatankuasa Menghalang Penyelesaian Keselamatan Komprehensif
Jawatankuasa piawaian C++ telah secara berkesan menolak cadangan Safe C++ oleh Sean Baxter , yang menjanjikan keselamatan memori yang lengkap sambil mengekalkan keserasian ke belakang sepenuhnya dengan kod sedia ada. Cadangan ini, yang disokong oleh pelaksanaan kerja yang dipanggil Circle , mewakili usaha individu selama bertahun-tahun untuk menyelesaikan masalah keselamatan C++ tanpa merosakkan pangkalan kod sedia ada. Penolakan itu datang melalui penggunaan prinsip reka bentuk yang kelihatan menghalang pendekatan sedemikian secara awal, menyebabkan ramai dalam komuniti mempersoalkan komitmen jawatankuasa terhadap penambahbaikan keselamatan yang bermakna.
Masa keputusan ini telah mencetuskan perdebatan sengit, terutamanya ketika bahasa lain seperti Rust terus mendapat tempat dalam domain pengaturcaraan sistem yang secara tradisinya dikuasai oleh C++ .
Garis Masa Cadangan Safe C++
- P3390R0: Cadangan Safe C++ dengan pelaksanaan Circle
- 2024-11 Mesyuarat Wrocław: Undian jawatankuasa mengenai pendekatan Safe C++
- P3466 R1: Prinsip reka bentuk yang diterima pakai telah menghalang penyelesaian gaya Safe C++
- Keputusan: Cadangan keselamatan yang komprehensif telah ditolak dengan berkesan
Dilema Keserasian ke Belakang
Perbincangan komuniti mendedahkan kekecewaan yang mendalam dengan komitmen C++ yang tidak berubah terhadap keserasian ke belakang. Ramai pembangun berpendapat bahawa obsesi ini menghalang bahasa daripada menangani kelemahan asas yang telah melanda ia selama beberapa dekad. Percanggahan itu jelas: projek sangat memerlukan ciri keselamatan moden, namun jawatankuasa enggan membuat perubahan yang boleh merosakkan yang dapat membolehkannya.
Jawatankuasa benar-benar mengecewakan visi C++ yang baik dengan enggan merosakkan keserasian ke belakang untuk memperbaiki masalah teras. Saya bercakap tentang jenis asas, penukaran tersirat, inisialisasi, prapemproses, tingkah laku tidak ditakrifkan / tidak betul NDR .
Ada yang mencadangkan bahawa kod warisan yang benar-benar jarang memerlukan ciri bahasa yang canggih, menjadikan hujah keserasian ke belakang kurang meyakinkan daripada yang kelihatan.
Realiti Industri vs Ideal Akademik
Perdebatan melangkaui pertimbangan teknikal kepada realiti ekonomi. Pangkalan kod besar yang mewakili kos pembangunan berbilion dolar Amerika Syarikat tidak boleh ditulis semula begitu sahaja. Syarikat dengan projek C++ yang berusia beberapa dekad mendapati diri mereka terperangkap antara keperluan untuk penambahbaikan keselamatan dan kemustahilan penulisan semula secara menyeluruh. Ini mewujudkan ekosistem yang kompleks di mana penambahbaikan berperingkat seperti tingkah laku yang salah menjadi berharga, walaupun ia tidak mencapai penyelesaian yang komprehensif.
Sementara itu, projek yang lebih baharu semakin memilih alternatif seperti Rust , yang menawarkan keselamatan memori mengikut reka bentuk dan bukannya sebagai pemikiran kemudian.
Keutamaan Bahasa Komuniti Mengikut Kes Penggunaan
- Pangkalan Kod Warisan: Terikat dengan C++ disebabkan kos penulisan semula (berbilion USD)
- Projek Baharu: Semakin memilih Rust untuk keselamatan memori
- Pembangunan Permainan: C++ kekal dominan dengan enjin Unreal, Godot
- Aplikasi GUI: Qt untuk C++ berbanding alternatif Rust yang muncul seperti egui
- Kritikal Prestasi: C++ dengan penggunaan subset berhati-hati berbanding blok unsafe Rust
Kebimbangan Prestasi dan Peralatan
Pengenalan tingkah laku yang salah bertujuan untuk menyediakan hasil yang boleh diramal untuk pembacaan pemboleh ubah yang tidak diinisialisasi sambil mengekalkan keupayaan diagnostik. Tidak seperti inisialisasi sifar yang mudah, pendekatan ini mengekalkan alat penyahpepijatan sedia ada yang membantu menangkap isu ini semasa pembangunan. Walau bagaimanapun, soalan kekal mengenai kesan prestasi dan sama ada vendor pengkompil akan benar-benar melaksanakan diagnostik yang disyorkan secara konsisten.
Atribut [[indeterminate]] menawarkan jalan keluar untuk kod kritikal prestasi yang sengaja menggunakan memori yang tidak diinisialisasi, mengikuti prinsip C++ jangan bayar untuk apa yang anda tidak gunakan.
Melihat ke Hadapan
Ketika C++ meneruskan evolusinya dengan keluaran yang dirancang berpotensi meluas hingga C++43 dan seterusnya, komuniti kekal berpecah sama ada penambahbaikan berperingkat dapat menangani cabaran asas bahasa tersebut. Walaupun sesetengah pembangun telah beralih kepada alternatif, yang lain terus bekerja dalam kekangan C++ , berharap untuk perubahan yang lebih besar dalam piawaian masa depan.
Penolakan cadangan keselamatan komprehensif menunjukkan jawatankuasa kekal komited kepada pendekatan semasanya, meninggalkan soalan yang lebih luas mengenai daya maju jangka panjang C++ dalam landskap pengaturcaraan yang semakin sedar keselamatan tidak diselesaikan.
Rujukan: C++26: erroneous behaviour