ภาษาโปรแกรมมิ่ง C++ กำลังอยู่ในจุดแยกทางขณะที่ชุมชนต่อสู้กับคำถามพื้นฐานเกี่ยวกับความปลอดภัย ความเข้ากันได้แบบย้อนหลัง และทิศทางอนาคตของภาษา ในขณะที่ C++26 นำเสนอ erroneous behaviour เพื่อจัดการกับปัญหาการอ่านตัวแปรที่ไม่ได้กำหนดค่าเริ่มต้น ความขัดแย้งที่สำคัญกว่าได้เกิดขึ้นเกี่ยวกับการจัดการข้อเสนอด้านความปลอดภัยแบบครอบคลุมของคณะกรรมการ
พฤติกรรมที่ผิดพลาดใน C++26 เปรียบเทียบกับทางเลือกอื่น
- สถานะปัจจุบัน (C++23): การอ่านค่าที่ไม่ได้กำหนดเริ่มต้นทำให้เกิดพฤติกรรมที่ไม่ได้กำหนด และการวินิจฉัยที่ไม่น่าเชื่อถือ
- การกำหนดค่าเริ่มต้นเป็นศูนย์: คาดเดาได้แต่อาจปิดบังข้อผิดพลาด ทำให้เครื่องมือวินิจฉัยใช้งานไม่ได้
- พฤติกรรมที่ผิดพลาด (C++26): พฤติกรรมที่ไม่ถูกต้องแต่มีการกำหนดไว้อย่างชัดเจน รักษาความสามารถในการวินิจฉัยไว้
- กลไกการยกเว้น: แอตทริบิวต์ [[indeterminate]] สำหรับโค้ดที่ต้องการประสิทธิภาพสูง
คณะกรรมการปิดกั้นโซลูชันความปลอดภัยแบบครอบคลุม
คณะกรรมการมาตรฐาน C++ ได้ปฏิเสธข้อเสนอ Safe C++ ของ Sean Baxter อย่างจริงจัง ซึ่งสัญญาว่าจะให้ความปลอดภัยด้านหน่วยความจำอย่างสมบูรณ์พร้อมรักษาความเข้ากันได้แบบย้อนหลังกับโค้ดที่มีอยู่ทั้งหมด ข้อเสนอนี้ซึ่งได้รับการสนับสนุนจากการใช้งานจริงที่เรียกว่า Circle แสดงถึงความพยายามของบุคคลเป็นเวลาหลายปีในการแก้ปัญหาความปลอดภัยของ C++ โดยไม่ทำลายโค้ดเบสที่มีอยู่ การปฏิเสธเกิดขึ้นผ่านการรับรองหลักการออกแบบที่ดูเหมือนจะปิดกั้นแนวทางดังกล่าวล่วงหน้า ทำให้หลายคนในชุมชนตั้งคำถามเกี่ยวกับความมุ่งมั่นของคณะกรรมการต่อการปรับปรุงความปลอดภัยที่มีความหมาย
จังหวะเวลาของการตัดสินใจนี้ได้จุดประกายการถกเถียงอย่างเข้มข้น โดยเฉพาะเมื่อภาษาอื่นๆ เช่น Rust ยังคงได้รับความนิยมในโดเมนการเขียนโปรแกรมระบบที่เคยถูกครอบงำโดย C++
ไทม์ไลน์ข้อเสนอ Safe C++
- P3390R0: ข้อเสนอ Safe C++ พร้อมการใช้งาน Circle
- การประชุม 2024-11 Wrocław: คณะกรรมการลงคะแนนเสียงเกี่ยวกับแนวทาง Safe C++
- P3466 R1: หลักการออกแบบที่ได้รับการรับรองซึ่งปิดกั้นโซลูชันในรูปแบบ Safe C++
- ผลลัพธ์: ข้อเสนอด้านความปลอดภัยที่ครอบคลุมถูกปฏิเสธอย่างมีประสิทธิผล
ภาวะกลืนไม่เข้าคายไม่ออกของความเข้ากันได้แบบย้อนหลัง
การอภิปรายในชุมชนเผยให้เห็นความหงุดหงิดอย่างลึกซึ้งต่อความมุ่งมั่นอย่างไม่ลดละของ C++ ต่อความเข้ากันได้แบบย้อนหลัง นักพัฒนาหลายคนโต้แย้งว่าความหมกมุ่นนี้ป้องกันไม่ให้ภาษาจัดการกับข้อบกพร่องพื้นฐานที่รบกวนมาเป็นทศวรรษ ความขัดแย้งนั้นชัดเจน: โปรเจกต์ต่างๆ ต้องการฟีเจอร์ความปลอดภัยสมัยใหม่อย่างยิ่ง แต่คณะกรรมการปฏิเสธที่จะทำการเปลี่ยนแปลงที่ทำลายความเข้ากันได้ซึ่งสามารถเปิดใช้งานฟีเจอร์เหล่านั้นได้
คณะกรรมการกำลังทำลายวิสัยทัศน์ของ C++ ที่ดีจริงๆ โดยการปฏิเสธที่จะทำลายความเข้ากันได้แบบย้อนหลังเพื่อแก้ไขปัญหาหลัก ผมกำลังพูดถึงประเภทพื้นฐน การแปลงโดยนัย การกำหนดค่าเริ่มต้น ตัวประมวลผลล่วงหน้า พฤติกรรมที่ไม่ได้กำหนด / ill-formed NDR
บางคนแนะนำว่าโค้ดเก่าแก่จริงๆ ไม่ค่อยต้องการฟีเจอร์ภาษาที่ทันสมัย ทำให้อาร์กิวเมนต์ความเข้ากันได้แบบย้อนหลังดูน่าเชื่อถือน้อยกว่าที่ปรากฏ
ความเป็นจริงของอุตสาหกรรม vs อุดมคติทางวิชาการ
การถกเถียงขยายไปเกินกว่าการพิจารณาทางเทคนิคสู่ความเป็นจริงทางเศรษฐกิจ โค้ดเบสขนาดใหญ่ที่แสดงถึงต้นทุนการพัฒนาหลายพันล้านดอลลาร์สหรัฐไม่สามารถเขียนใหม่ทั้งหมดได้ บริษัทที่มีโปรเจกต์ C++ อายุหลายทศวรรษพบว่าตัวเองติดอยู่ระหว่างความต้องการปรับปรุงความปลอดภัยและความเป็นไปไม่ได้ของการเขียนใหม่ทั้งหมด สิ่งนี้สร้างระบบนิเวศที่ซับซ้อนซึ่งการปรับปรุงแบบค่อยเป็นค่อยไปเช่น erroneous behaviour กลายเป็นสิ่งที่มีค่า แม้ว่าจะไม่ถึงระดับโซลูชันที่ครอบคลุม
ในขณะเดียวกัน โปรเจกต์ใหม่ๆ เลือกทางเลือกอื่นเช่น Rust มากขึ้น ซึ่งเสนอความปลอดภัยด้านหน่วยความจำโดยการออกแบบมากกว่าเป็นสิ่งที่คิดทีหลัง
การเลือกใช้ภาษาโปรแกรมของชุมชนนักพัฒนาตามกรณีการใช้งาน
- โค้ดเบสเก่า: ติดอยู่กับ C++ เนื่องจากต้นทุนการเขียนใหม่ (หลายพันล้านดอลลาร์สหรัฐ)
- โปรเจกต์ใหม่: เลือกใช้ Rust มากขึ้นเพื่อความปลอดภัยของหน่วยความจำ
- การพัฒนาเกม: C++ ยังคงครองตำแหน่งผู้นำด้วยเอนจิน Unreal, Godot
- แอปพลิเคชัน GUI: Qt สำหรับ C++ เทียบกับทางเลือกใหม่ของ Rust อย่าง egui
- งานที่ต้องการประสิทธิภาพสูง: C++ ที่ใช้ subset อย่างระมัดระวัง เทียบกับ unsafe blocks ของ Rust
ข้อกังวลด้านประสิทธิภาพและเครื่องมือ
การนำเสนอ erroneous behaviour มีเป้าหมายเพื่อให้ผลลัพธ์ที่คาดเดาได้สำหรับการอ่านตัวแปรที่ไม่ได้กำหนดค่าเริ่มต้นพร้อมรักษาความสามารถในการวินิจฉัย ต่างจากการกำหนดค่าเป็นศูนย์อย่างง่ายๆ แนวทางนี้รักษาเครื่องมือดีบักที่มีอยู่ซึ่งช่วยตรวจจับปัญหาเหล่านี้ระหว่างการพัฒนา อย่างไรก็ตาม คำถามยังคงอยู่เกี่ยวกับผลกระทบต่อประสิทธิภาพและว่าผู้จำหน่ายคอมไพเลอร์จะใช้งานการวินิจฉัยที่แนะนำอย่างสม่ำเสมอหรือไม่
แอตทริบิวต์ [[indeterminate]] เสนอทางออกสำหรับโค้ดที่ต้องการประสิทธิภาพสูงซึ่งใช้หน่วยความจำที่ไม่ได้กำหนดค่าเริ่มต้นโดยเจตนา ตามหลักการ don't pay for what you don't use ของ C++
มองไปข้างหน้า
ขณะที่ C++ ยังคงวิวัฒนาการด้วยการวางแผนการเผยแพร่ที่อาจขยายไปถึง C++43 และต่อไป ชุมชนยังคงแบ่งแยกเกี่ยวกับว่าการปรับปรุงแบบค่อยเป็นค่อยไปสามารถจัดการกับความท้าทายพื้นฐานของภาษาได้หรือไม่ ในขณะที่นักพัฒนาบางคนได้ย้ายไปใช้ทางเลือกอื่นแล้ว คนอื่นๆ ยังคงทำงานภายใต้ข้อจำกัดของ C++ โดยหวังว่าจะมีการเปลี่ยนแปลงที่สำคัญกว่าในมาตรฐานอนาคต
การปฏิเสธข้อเสนอความปลอดภัยแบบครอบคลุมแสดงให้เห็นว่าคณะกรรมการยังคงมุ่งมั่นต่อแนวทางปัจจุบัน ทำให้คำถามที่กว้างขึ้นเกี่ยวกับความสามารถในการอยู่รอดระยะยาวของ C++ ในภูมิทัศน์การเขียนโปรแกรมที่ใส่ใจความปลอดภัยมากขึ้นยังไม่ได้รับการแก้ไข
อ้างอิง: C++26: erroneous behaviour