Komuniti pengaturcaraan C++ sedang menyaksikan perdebatan yang tidak pernah berlaku sebelum ini mengenai salah satu ciri paling bercita-cita tinggi dalam bahasa tersebut. Selepas lebih daripada lima tahun sejak C++20 memperkenalkan modul, semakin ramai pembangun dan pakar mempersoalkan sama ada ciri ini patut kekal dalam standard sama sekali.
Kontroversi ini berpunca daripada realiti yang jelas: walaupun telah bertahun-tahun usaha pembangunan, modul C++ telah gagal memenuhi janji utama mereka untuk memberikan masa kompilasi yang jauh lebih pantas. Apa yang pernah digembar-gemburkan sebagai penyelesaian kepada masalah kelajuan pembinaan yang terkenal buruk dalam C++ sebaliknya telah menjadi sumber kekecewaan bagi pembangun yang cuba menggunakan amalan C++ moden.
Janji Prestasi Yang Tidak Pernah Menjadi Kenyataan
Apabila modul C++ mula-mula dicadangkan, titik jualan utama adalah jelas - peningkatan kelajuan kompilasi yang besar. Sistem penyertaan header tradisional mencipta algoritma O(N²) di mana kod yang sama diuraikan berulang kali merentasi pelbagai fail sumber. Modul sepatutnya menyelesaikan masalah ini dengan menyimpan kod yang telah diproses dalam format binari yang boleh dimuatkan dengan cepat dari cakera.
Walau bagaimanapun, ujian dunia sebenar mendedahkan cerita yang berbeza. Pelaksanaan semasa menunjukkan hanya peningkatan sederhana sebanyak 10-20% dalam kes terbaik, jauh daripada keuntungan transformatif yang dijanjikan pada asalnya. Sesetengah ahli komuniti telah menemui bahawa teknik sedia ada, seperti perpustakaan standard yang direka dengan teliti, sudah boleh mencapai peningkatan kelajuan kompilasi 4x tanpa memerlukan kerumitan yang diperkenalkan oleh modul.
Keadaan menjadi lebih membimbangkan apabila mempertimbangkan bahawa header yang telah dikompil terlebih dahulu, teknologi yang jauh lebih lama, sering memberikan keuntungan prestasi yang sama atau lebih baik dengan kerumitan pelaksanaan yang jauh kurang. Ini menimbulkan persoalan asas tentang sama ada usaha kejuruteraan besar yang dilaburkan dalam modul berbaloi.
Prestasi Modul Semasa berbanding Jangkaan
- Janji Asal: Peningkatan kelajuan kompilasi 5x-10x
- Realiti Semasa: Peningkatan 10-20% dalam kes terbaik
- Precompiled Headers: Sering kali prestasi setara atau lebih baik
- Penyelesaian Alternatif: ZapCC mencapai peningkatan kelajuan 5x+ menggunakan teknologi sedia ada
Kekacauan Pelaksanaan Merentasi Kompiler
Salah satu aspek paling merosakkan dalam pelancaran modul ialah kekurangan koordinasi antara vendor kompiler dan pembangun sistem pembinaan. Setiap kompiler utama telah melaksanakan modul secara berbeza, mewujudkan ekosistem yang berpecah-belah di mana kod yang berfungsi dengan satu rantaian alat mungkin gagal dengan yang lain.
Cabaran integrasi adalah sangat teruk sehingga sistem pembinaan kini mesti menjana bendera kompiler tambahan semasa kompilasi, menyimpannya dalam fail sementara, dan menyerahkannya kepada arahan kompilasi seterusnya. Tahap kerumitan ini sangat berbeza dengan kesederhanaan elegan yang sepatutnya dibawa oleh modul kepada pembangunan C++ .
Kami tidak mahu mengubah kompiler menjadi sistem pembinaan telah menjadi respons biasa daripada pembangun kompiler apabila berhadapan dengan cadangan untuk memperbaiki integrasi modul, dengan berkesan mewujudkan kebuntuan di mana tiada pihak mahu bertanggungjawab untuk membuat sistem berfungsi dengan lancar.
Kekurangan pemilik produk bersatu yang mempunyai kuasa ke atas semua bahagian yang bergerak telah mewujudkan apa yang digambarkan oleh ramai sebagai mimpi ngeri kerumitan yang kafkaesque. Tanpa seseorang yang diberi kuasa untuk menyelaras antara pasukan kompiler, penyelenggara sistem pembinaan, dan pelaksana perpustakaan standard, modul kekal tersekat dalam keadaan kefungsian separa.
Cabaran Pelaksanaan Utama
- Perpecahan Pengkompil: Setiap vendor melaksanakan modul dengan cara yang berbeza
- Integrasi Sistem Binaan: Memerlukan pengurusan fail sementara yang kompleks
- Isu Kebolehpindahan: Fail binari modul tidak boleh dipindahkan antara pengkompil (kecuali MSVC )
- Sokongan Rantaian Alat: Sokongan modul Apple masih disenaraikan sebagai "separa"
- Kod Warisan: Tidak boleh mencampurkan
include <vector>danimport <vector>dalam projek yang sama
Belajar Daripada Pendekatan Alternatif
Perbincangan komuniti telah menyerlahkan beberapa pendekatan alternatif yang mungkin lebih berjaya. Sesetengah pembangun menunjuk kepada bahasa pengaturcaraan D , yang melaksanakan sistem modul yang bersih lebih dua dekad lalu yang terus berfungsi dengan boleh dipercayai. Pendekatan D termasuk ciri seperti ruang nama tertutup dan kebebasan semantik yang menjadikan modul benar-benar terpencil dan boleh diramal.
Cadangan lain memfokuskan kepada penyelesaian yang lebih mudah yang boleh memberikan sebahagian besar faedah dengan kerumitan yang jauh kurang. Penyata import yang mudah yang berfungsi seperti include tetapi tanpa kebocoran konteks boleh dilaksanakan dengan lebih mudah sambil masih membolehkan pengoptimuman kompiler yang ketara.
Alat seperti ZapCC , yang mencapai peningkatan kelajuan kompilasi 5x+ melalui proses kompiler yang berterusan, menunjukkan bahawa peningkatan masa pembinaan yang dramatik sudah mungkin menggunakan teknologi sedia ada. Penyelesaian ini sebahagian besarnya diabaikan memihak kepada pendekatan modul yang lebih kompleks.
Jalan Ke Hadapan
Apabila perdebatan semakin sengit, beberapa hasil yang berpotensi sedang dibincangkan. Ada yang berhujah untuk mengeluarkan modul sepenuhnya daripada standard dan memulakan semula dengan pendekatan yang lebih mudah. Yang lain mencadangkan untuk memberi tumpuan kepada subset import std , yang boleh memberikan faedah bermakna untuk penggunaan perpustakaan standard tanpa memerlukan kerumitan penuh modul am.
Cabaran asas kekal bahawa modul memerlukan koordinasi meluas antara pelbagai organisasi bebas, masing-masing dengan keutamaan dan kekangan mereka sendiri. Tanpa struktur tadbir urus yang jelas dan komitmen bersama untuk membuat modul berfungsi dengan betul, ciri ini mungkin kekal dilaksanakan separuh secara kekal.
Komuniti C++ kini menghadapi pilihan yang sukar: terus melabur sumber dalam ciri yang secara konsisten gagal memenuhi jangkaan, atau mengakui cabaran pelaksanaan dan meneruskan pendekatan alternatif yang boleh memberikan peningkatan kelajuan kompilasi yang sangat diperlukan oleh pembangun.
Rujukan: Nibble Stew