Bahasa pemrograman C++ berada di persimpangan jalan saat komunitas bergulat dengan pertanyaan fundamental tentang keamanan, kompatibilitas mundur, dan arah masa depan bahasa tersebut. Sementara C++26 memperkenalkan erroneous behaviour untuk mengatasi pembacaan variabel yang tidak diinisialisasi, kontroversi yang lebih signifikan telah muncul seputar penanganan komite terhadap proposal keamanan yang komprehensif.
Perilaku Keliru C++26 vs Alternatif Lainnya
- Status Quo ( C++23 ): Pembacaan yang tidak diinisialisasi menyebabkan perilaku tidak terdefinisi, diagnostik tidak dapat diandalkan
- Inisialisasi Nol: Dapat diprediksi tetapi berpotensi menyembunyikan bug, membatalkan alat diagnostik
- Perilaku Keliru ( C++26 ): Perilaku salah yang terdefinisi dengan baik, mempertahankan kemampuan diagnostik
- Mekanisme Opt-out: Atribut [[indeterminate]] untuk kode yang kritis terhadap performa
Komite Memblokir Solusi Keamanan Komprehensif
Komite standar C++ secara efektif telah menolak proposal Safe C++ milik Sean Baxter , yang menjanjikan keamanan memori lengkap sambil mempertahankan kompatibilitas mundur penuh dengan kode yang ada. Proposal ini, didukung oleh implementasi kerja yang disebut Circle , mewakili upaya individual selama bertahun-tahun untuk menyelesaikan masalah keamanan C++ tanpa merusak basis kode yang ada. Penolakan tersebut datang melalui adopsi prinsip desain yang tampaknya secara preventif menutup pendekatan semacam itu, membuat banyak orang di komunitas mempertanyakan komitmen komite terhadap perbaikan keamanan yang bermakna.
Waktu keputusan ini telah memicu perdebatan sengit, terutama karena bahasa lain seperti Rust terus mendapat tempat di domain pemrograman sistem yang secara tradisional didominasi oleh C++.
Timeline Proposal Safe C++
- P3390R0: Proposal Safe C++ dengan implementasi Circle
- Pertemuan Wrocław 2024-11: Pemungutan suara komite mengenai pendekatan Safe C++
- P3466 R1: Prinsip desain yang diadopsi yang menutup kemungkinan solusi bergaya Safe C++
- Hasil: Proposal keamanan komprehensif secara efektif ditolak
Dilema Kompatibilitas Mundur
Diskusi komunitas mengungkapkan frustrasi mendalam terhadap komitmen C++ yang tak tergoyahkan pada kompatibilitas mundur. Banyak pengembang berargumen bahwa obsesi ini mencegah bahasa tersebut mengatasi kelemahan fundamental yang telah mengganggu selama beberapa dekade. Kontradiksinya mencolok: proyek-proyek sangat membutuhkan fitur keamanan modern, namun komite menolak membuat perubahan yang merusak yang dapat memungkinkan hal tersebut.
Komite benar-benar mengecewakan visi C++ yang baik dengan menolak merusak kompatibilitas mundur untuk memperbaiki masalah inti. Saya berbicara tentang tipe fundamental, konversi implisit, inisialisasi, preprocessor, perilaku undefined / ill-formed NDR.
Beberapa menyarankan bahwa kode legacy sejati jarang membutuhkan fitur bahasa mutakhir, membuat argumen kompatibilitas mundur kurang meyakinkan dari yang terlihat.
Realitas Industri vs Ideal Akademis
Perdebatan meluas melampaui pertimbangan teknis ke realitas ekonomi. Basis kode besar yang mewakili biaya pengembangan miliaran dolar Amerika Serikat tidak dapat begitu saja ditulis ulang. Perusahaan dengan proyek C++ berusia puluhan tahun menemukan diri mereka terjebak antara kebutuhan akan perbaikan keamanan dan ketidakmungkinan penulisan ulang secara menyeluruh. Ini menciptakan ekosistem kompleks di mana perbaikan bertahap seperti erroneous behaviour menjadi berharga, meskipun tidak mencapai solusi komprehensif.
Sementara itu, proyek-proyek yang lebih baru semakin memilih alternatif seperti Rust , yang menawarkan keamanan memori berdasarkan desain daripada sebagai tambahan.
Preferensi Bahasa Pemrograman Komunitas Berdasarkan Kasus Penggunaan
- Basis Kode Lama: Terjebak dengan C++ karena biaya penulisan ulang (miliaran USD)
- Proyek Baru: Semakin banyak memilih Rust untuk keamanan memori
- Pengembangan Game: C++ tetap dominan dengan engine Unreal , Godot
- Aplikasi GUI: Qt untuk C++ vs alternatif Rust yang muncul seperti egui
- Kritis Performa: C++ dengan penggunaan subset yang hati-hati vs blok unsafe Rust
Kekhawatiran Performa dan Tooling
Pengenalan erroneous behaviour bertujuan untuk memberikan hasil yang dapat diprediksi untuk pembacaan variabel yang tidak diinisialisasi sambil mempertahankan kemampuan diagnostik. Tidak seperti zero-initialization sederhana, pendekatan ini mempertahankan alat debugging yang ada yang membantu menangkap masalah ini selama pengembangan. Namun, pertanyaan tetap ada tentang dampak performa dan apakah vendor compiler akan benar-benar mengimplementasikan diagnostik yang direkomendasikan secara konsisten.
Atribut [[indeterminate]] menawarkan jalan keluar untuk kode yang kritis terhadap performa yang sengaja menggunakan memori yang tidak diinisialisasi, mengikuti prinsip C++ don't pay for what you don't use.
Melihat ke Depan
Saat C++ melanjutkan evolusinya dengan rilis yang direncanakan berpotensi meluas hingga C++43 dan seterusnya, komunitas tetap terbagi tentang apakah perbaikan bertahap dapat mengatasi tantangan fundamental bahasa tersebut. Sementara beberapa pengembang telah pindah ke alternatif, yang lain terus bekerja dalam batasan C++, berharap perubahan yang lebih substansial dalam standar masa depan.
Penolakan proposal keamanan komprehensif menunjukkan komite tetap berkomitmen pada pendekatan saat ini, meninggalkan pertanyaan yang lebih luas tentang viabilitas jangka panjang C++ dalam lanskap pemrograman yang semakin sadar keamanan tetap tidak terselesaikan.
Referensi: C++26: erroneous behaviour