คณะกรรมการมาตรฐาน C++ ได้ตัดสินใจอย่างเป็นทางการที่จะละทิ้งข้อเสนอ Safe C++ ที่ทะเยอทะยานเพื่อหันไปใช้แนวทางที่อนุรักษ์นิยมมากกว่าที่เรียกว่า Profiles การตัดสินใจนี้ได้จุดประกายการอภิปรายอย่างร้อนแรงในชุมชนโปรแกรมเมอร์เกี่ยวกับอนาคตของความปลอดภัยหน่วยความจำในหนึ่งในภาษาโปรแกรมที่ใช้กันอย่างแพร่หลายที่สุดในโลก
ข้อเสนอ Safe C++ ที่เปิดตัวเมื่อปีที่แล้ว มีเป้าหมายที่จะนำการรับประกันความปลอดภัยแบบ Rust มาสู่ C++ ผ่านระบบ safe context แบบ opt-in ข้อเสนอนี้สัญญาว่าจะให้ความปลอดภัยหน่วยความจำที่แข็งแกร่ง ความปลอดภัยของประเภทข้อมูล และความปลอดภัยของเธรดโดยไม่ทำลายโค้ดที่มีอยู่ นักพัฒนาสามารถทำเครื่องหมายส่วนเฉพาะของโค้ดให้ปลอดภัยในขณะที่ปล่อยให้ส่วน legacy ไม่เปลี่ยนแปลง สร้างเส้นทางการย้ายแบบค่อยเป็นค่อยไปสู่แนวทางการเขียนโปรแกรมที่ปลอดภัยกว่า
การเปรียบเทียบ Safe C++ กับ Profiles
| ด้าน | ข้อเสนอ Safe C++ | แนวทาง Profiles |
|---|---|---|
| ระดับความปลอดภัย | รับประกันความปลอดภัยเทียบเท่า Rust | จำกัด เป็นเพียงการตรวจสอบแบบ linter |
| การนำไปใช้ | syntax และโครงสร้างภาษาใหม่ | ข้อจำกัดในฟีเจอร์ที่มีอยู่ |
| เส้นทางการย้าย | เลือกใช้ safe contexts | ข้อจำกัดในเวลา compile |
| ความเข้ากันได้แบบย้อนหลัง | เข้ากันได้เต็มรูปแบบกับโค้ดที่มีอยู่ | เข้ากันได้เต็มรูปแบบกับโค้ดที่มีอยู่ |
| สถานะของคณะกรรมการ | ถูกยกเลิก | ดำเนินการอย่างแข็งขัน |
| ความซับซ้อนทางเทคนิค | สูง (borrow checker, lifetimes) | ปานกลาง (ตามข้อจำกัด) |
คณะกรรมการให้ความสำคัญกับความเข้ากันได้แบบย้อนหลังมากกว่าการเปลี่ยนแปลงที่ปฏิวัติ
Sean Baxter หนึ่งในผู้เขียน Safe C++ คนแรก ยืนยันว่ากลุ่มงาน Safety and Security ได้ลงคะแนนให้ความสำคัญกับ Profiles มากกว่าข้อเสนอที่ทะเยอทะยานมากกว่า ความต้านทานของคณะกรรมการต่อการนำกลไกความปลอดภัยแบบ Rust มาใช้สะท้อนถึงความตึงเครียดทางวัฒนธรรมที่ลึกซึ้งภายในชุมชน C++ สมาชิกคณะกรรมการหลายคนมองว่าแบบจำลองความปลอดภัยของ Rust เป็นการออกห่างจากปรัชญาดั้งเดิมของ C++ อย่างรุนแรงเกินไป
Profiles แสดงถึงแนวทางที่แตกต่างโดยพื้นฐานต่อความปลอดภัย แทนที่จะแนะนำโครงสร้างภาษาใหม่อย่างที่ Safe C++ เสนอ Profiles ทำงานโดยการจำกัดฟีเจอร์และรูปแบบการใช้งานของ C++ ที่มีอยู่ คิดว่าเป็นแนวทางการเขียนโค้ดที่บังคับใช้โดยคอมไพเลอร์ที่สามารถตรวจจับข้อผิดพลาดทั่วไปโดยไม่ต้องให้นักพัฒนาเรียนรู้ไวยากรณ์หรือแนวคิดใหม่ทั้งหมด
ข้อจำกัดทางเทคนิคก่อให้เกิดความสงสัย
ความสามารถทางเทคนิคของ Profiles ได้รับการวิพากษ์วิจารณ์อย่างรุนแรงจากผู้สนับสนุนความปลอดภัย ไม่เหมือนกับ Safe C++ หรือ borrow checker ของ Rust, Profiles ไม่สามารถให้การรับประกันทางคณิตศาสตร์ในระดับเดียวกันเกี่ยวกับความปลอดภัยหน่วยความจำ ระบบนี้ทำหน้าที่เป็น linter ขั้นสูงมากกว่าจะเป็นกลไกความปลอดภัยพื้นฐาน
เทคโนโลยี profiles ไม่ค่อยดีนัก แต่นั่นไม่สำคัญเมื่อเทียบกับปัญหาวัฒนธรรม เมื่อคุณตัดสินใจทำให้เพลง bagpipe ที่เศร้าโศกยาวสิบห้านาทีเป็นซิงเกิลหลัก มันไม่สำคัญหรอกว่าคุณจะใช้ไวนิลสีหรือไม่
นักวิจารณ์โต้แย้งว่า Profiles เผชิญกับความท้าทายที่ไม่สามารถเอาชนะได้เมื่อต้องจัดการกับโค้ด C++ ในโลกแห่งความเป็นจริง ประเภทการอ้างอิงที่ไม่ใช่เจ้าของ ซึ่งจำเป็นสำหรับประสิทธิภาพในแอปพลิเคชันหลายตัว ไม่สามารถจัดการได้อย่างปลอดภัยโดยไม่มีฟีเจอร์ภาษาที่ซับซ้อนมากขึ้นเช่นการติดตามอายุการใช้งาน ในขณะที่นักพัฒนาต้องการใช้รูปแบบทั่วไปเช่น string_view การรับประกันความปลอดภัยเริ่มพังทลาย
ข้อจำกัดทางเทคนิคหลักของ Profiles
- ไม่สามารถจัดการกับ non-owning reference types ได้อย่างปลอดภัย
- ไม่มีความสามารถในการติดตาม lifetime
- จำกัดเพียงข้อจำกัดในเวลา compile-time บนฟีเจอร์ที่มีอยู่
- มีปัญหากับรูปแบบทั่วไปเช่น
string_view - ให้การรับประกันที่อ่อนแอกว่าระบบพิสูจน์ทางคณิตศาสตร์
- ทำงานเหมือน advanced static analyzer มากกว่าระบบความปลอดภัย
ชุมชนแบ่งแยกเกี่ยวกับเส้นทางไปข้างหน้า
การตัดสินใจนี้ได้เปิดเผยการแบ่งแยกพื้นฐานในชุมชน C++ ผู้ที่หลงใหล C++ มายาวนานที่ทำหน้าที่ในคณะกรรมการมาตรฐานมีแนวโน้มที่จะต่อต้านการเปลี่ยนแปลงอย่างมากที่อาจทำให้ผู้ใช้ที่มีอยู่รู้สึกห่างเหิน ในขณะเดียวกัน นักพัฒนาที่ทำงานกับแอปพลิเคชันที่สำคัญด้านความปลอดภัยพบว่าตัวเองถูกบังคับให้พิจารณาทางเลือกอื่นเช่น Rust มากขึ้น
สมาชิกชุมชนบางคนแนะนำให้ทำตามแบบจำลอง HTML5 ที่ผู้ผลิตเบราว์เซอร์ข้ามองค์กรมาตรฐาน W3C อย่างเป็นหลักเพื่อสร้าง WHATWG อย่างไรก็ตาม ไม่เหมือนกับเว็บเบราว์เซอร์ที่บริษัทใหญ่ไม่กี่แห่งควบคุมการดำเนินการ คอมไพเลอร์ C++ ได้รับการพัฒนาโดยกลุ่มที่หลากหลายซึ่งมีลำดับความสำคัญและทรัพยากรที่แตกต่างกัน
ช่วงเวลาของการตัดสินใจนี้สร้างแรงกดดันเพิ่มเติม เนื่องจากกระบวนการของคณะกรรมการใช้เวลาหลายปีหรือแม้กระทั่งหลายทศวรรษ ฟีเจอร์ความปลอดภัยใดๆ ที่ไม่ได้มาตรฐานในเร็วๆ นี้อาจมาถึงช้าเกินไปที่จะป้องกันการกัดเซาะตำแหน่งของ C++ ในการเขียนโปรแกรมระบบต่อไป ภาษาเช่น Rust และแม้กระทั่งทางเลือกใหม่กว่าเช่น Zig ยังคงได้รับพื้นที่ในโดเมนที่ถูกครอบงำโดย C++ แบบดั้งเดิม
มองไปข้างหน้า: ความก้าวหน้าแบบค่อยเป็นค่อยไปหรือโอกาสที่พลาดไป?
แม้ว่า Profiles อาจให้การปรับปรุงบางอย่างเมื่อเทียบกับสถานการณ์ปัจจุบัน นักพัฒนาหลายคนตั้งคำถามว่ามาตรการความปลอดภัยแบบค่อยเป็นค่อยไปสามารถจัดการกับความท้าทายพื้นฐานที่ C++ เผชิญได้หรือไม่ แนวทางนี้อาจช่วยตรวจจับบั๊กทั่วไปบางอย่าง แต่ยังไม่เพียงพอที่จะให้การรับประกันความปลอดภัยที่ครอบคลุมซึ่งการพัฒนาซอฟต์แวร์สมัยใหม่ต้องการมากขึ้น
การตัดสินใจของคณะกรรมการสะท้อนถึงความตึงเครียดที่กว้างขึ้นระหว่างการรักษาฐานโค้ดขนาดใหญ่ที่มีอยู่ของ C++ และการปรับตัวให้เข้ากับข้อกำหนดความปลอดภัยร่วมสมัย ว่าแนวทางอนุรักษ์นิยมนี้จะเพียงพอที่จะรักษาความเกี่ยวข้องของ C++ ในภูมิทัศน์การเขียนโปรแกรมที่ใส่ใจความปลอดภัยมากขึ้นหรือไม่ยังคงเป็นคำถามที่เปิดอยู่
ในตอนนี้ นักพัฒนาที่แสวงหาการรับประกันความปลอดภัยที่แข็งแกร่งอาจต้องมองไปไกลกว่ามาตรฐาน C++ อย่างเป็นทางการไปยังเครื่องมือทดลอง การดำเนินการทางเลือก หรือภาษาที่แตกต่างกันโดยสิ้นเชิง การละทิ้งข้อเสนอ Safe C++ ไม่ได้เป็นเพียงการตัดสินใจทางเทคนิค แต่เป็นการเลือกเชิงปรัชญาเกี่ยวกับทิศทางอนาคตของภาษา