ข้อเสนอล่าสุดสำหรับ safe pointer ใน C++ ที่ออกแบบมาเพื่อป้องกัน use-after-free bugs และจัดการกับการย้าย object ได้จุดประกายการอภิปรายในชุมชนโปรแกรมเมอร์ โซลูชันที่เสนอมีเป้าหมายเพื่อแก้ไขปัญหาความปลอดภัยของหน่วยความจำใน C++ โดยใช้ shared pointer ในการจัดการ heap-allocated pointer แต่นักพัฒนาตั้งคำถามว่าสิ่งนี้เป็นการประดิษฐ์ฟีเจอร์ที่มีอยู่แล้วใน standard library ขึ้นมาใหม่หรือไม่
คุณสมบัติของ Safe Pointer ที่เสนอ:
- การทำให้เป็น null โดยอัตโนมัติเมื่อ pointee ถูกทำลาย
- การอัปเดต pointer เมื่อ pointee ถูกย้าย
- การใช้ double indirection ผ่าน shared_ptr<T*>
- การออกแบบแบบ single-threaded (ไม่มี atomic operations)
- ต้องการการสืบทอดจาก base class ของ safe_ptr_factory
ชุมชนตั้งคำถามเกี่ยวกับโซลูชันที่มีอยู่แล้ว
การวิพากษ์วิจารณ์ที่สำคัญที่สุดมุ่งเน้นไปที่การทับซ้อนของข้อเสนอกับ std::weak_ptr ซึ่งมีให้ใช้งานตั้งแต่ C++11 สมาชิกในชุมชนชี้ให้เห็นว่าการออกแบบที่เสนอนั้นสร้างฟังก์ชันการทำงานที่มีอยู่แล้วใน standard library ขึ้นมาใหม่ ผู้เขียนยอมรับข้อกังวลนี้และอธิบายว่าการใช้งานจริงของพวกเขาใช้ single-threaded shared pointer โดยไม่มี atomic operations เพื่อหลีกเลี่ยง performance overhead แต่แทนที่ด้วย std::shared_ptr ในบล็อกโพสต์เพื่อให้เข้าถึงได้ง่ายขึ้น
การอภิปรายเผยให้เห็นปัญหาที่ลึกซึ้งยิ่งขึ้นเกี่ยวกับเวลาที่ควรใช้โซลูชัน standard library เทียบกับการใช้งานแบบกำหนดเอง นักพัฒนาบางคนโต้แย้งว่าหากข้อกำหนดเรื่อง memory layout ป้องกันการใช้ std::shared_ptr สำหรับการจัดการ object ทางเลือกอื่นเช่น vector-based indexing อาจเหมาะสมกว่าการสร้าง pointer types ใหม่ทั้งหมด
ทางเลือกจาก Standard Library:
std::weak_ptr- มีให้ใช้งานตั้งแต่ C++11 ให้การรับประกันความปลอดภัยในระดับเดียวกันstd::shared_ptr- จัดการอายุการใช้งานของออบเจ็กต์ด้วยการนับอ้างอิงstd::atomic<std::shared_ptr<T>>- เวอร์ชันที่ปลอดภัยสำหรับ thread ในสถานการณ์ multi-threaded- Vector + index handles - ทางเลือกสำหรับข้อกำหนดเรื่อง memory layout
ข้อกังวลเรื่องประสิทธิภาพและ Thread Safety
ข้อจำกัดแบบ single-threaded ของการออกแบบที่เสนอได้รับการวิพากษ์วิจารณ์จากนักพัฒนาที่มองว่า multi-threading เป็นสิ่งจำเป็นในแอปพลิเคชันสมัยใหม่ อย่างไรก็ตาม ผู้เขียนได้ชี้แจงว่า single-threaded semantics ยังคงมีคุณค่าในแอปพลิเคชัน multi-core ที่ใช้ threads แยกกันโดยไม่มี shared state หรือใช้สถาปัตยกรรม message-passing
การอภิปรายเรื่องประสิทธิภาพเน้นประเด็นที่น่าสนใจเกี่ยวกับ atomic operations ในการใช้งาน standard library แม้จะไม่มีการแข่งขัน atomic reference counting ก็ไม่ฟรี และนักพัฒนาบางคนสังเกตว่าการใช้งานบางอย่างเช่น GNU 's libstdc++ จริงๆ แล้วปรับให้เหมาะสมโดยการลบ atomic operations เมื่อตรวจพบการใช้งานแบบ single-threaded
ข้อพิจารณาด้านประสิทธิภาพ:
- ค่าใช้จ่ายเพิ่มเติมจากการอ้างอิงผ่าน pointer สองชั้น
- การจัดสรรหน่วยความจำใน heap สำหรับ shared state
- การตรวจสอบ null pointer เมื่อเข้าถึงข้อมูล
- ค่าใช้จ่ายของ atomic operations ใน shared_ptr มาตรฐาน (แม้จะไม่มีการแข่งขันกันใช้ทรัพยากร)
- การปรับปรุงประสิทธิภาพของ GNU libstdc++ : ลบ atomics เมื่อตรวจพบการทำงานแบบ single-threaded
แนวทางทางเลือกเริ่มปรากฏ
สมาชิกในชุมชนได้เสนอแนะโซลูชันทางเลือกหลายแนวทางสำหรับปัญหาความปลอดภัยของหน่วยความจำ แนวทางหนึ่งเกี่ยวข้องกับ generational indexing ซึ่ง objects ถูกจัดการโดย long-lived manager และการค้นหาจะล้มเหลวอย่างสง่างามเมื่อ objects ถูกทำลาย รูปแบบนี้มีประโยชน์อย่างยิ่งในการพัฒนาเกมและโดเมนอื่นๆ ที่ object lifetimes ถูกจัดการแบบรวมศูนย์
Multi-threading ไม่ได้หมายถึง shared ownership เสมอไป แต่ยังสามารถทำได้ด้วย message passing
คนอื่นๆ อ้างอิงถึงการใช้งานที่มีอยู่แล้วเช่น Chromium 's base::WeakPtr ซึ่งให้ฟังก์ชันการทำงานที่คล้ายกันแต่มีการรับประกันเฉพาะ thread ตัวอย่างในโลกแห่งความเป็นจริงเหล่านี้แสดงให้เห็นว่าปัญหาพื้นฐานนั้นเป็นที่เข้าใจกันดีและได้รับการแก้ไขในรูปแบบต่างๆ ข้าม codebase ที่แตกต่างกัน
ผลกระทบที่กว้างขึ้นสำหรับการพัฒนา C++
การถกเถียงสะท้อนความตึงเครียดที่ดำเนินต่อไปในการพัฒนา C++ ระหว่างการสร้างโซลูชันแบบกำหนดเองและการใช้ประโยชน์จากฟีเจอร์ standard library สมาชิกในชุมชนบางคนมองข้อเสนอนี้เป็นตัวอย่างของโค้ดที่ซับซ้อนโดยไม่จำเป็นซึ่งสามารถแก้ไขได้ดีกว่าผ่านเครื่องมือที่มีอยู่แล้วหรือแนวทางสถาปัตยกรรมที่แตกต่างกัน
การอภิปรายยังสัมผัสถึงการศึกษา C++ และความตระหนักรู้เกี่ยวกับฟีเจอร์ standard library ความจริงที่ว่า std::weak_ptr ไม่ได้ถูกกล่าวถึงในข้อเสนอเดิมแสดงให้เห็นว่าแม้แต่นักพัฒนาที่มีประสบการณ์อาจไม่ทราบโซลูชัน standard library ทั้งหมดที่มีอยู่สำหรับปัญหาทั่วไป
ในขณะที่การออกแบบ safe pointer ที่เสนอแสดงให้เห็นการแก้ปัญหาอย่างสร้างสรรค์ การตอบสนองของชุมชนเน้นความสำคัญของการทำความเข้าใจฟีเจอร์ standard library ที่มีอยู่อย่างละเอียดก่อนพัฒนาทางเลือกแบบกำหนดเอง การถกเถียงทำหน้าที่เป็นการเตือนใจว่า standard library ที่กว้างขวางของ C++ มักให้โซลูชันสำหรับปัญหาทั่วไป แม้ว่าจะต้องใช้แนวทางสถาปัตยกรรมที่แตกต่างจากที่คิดไว้ในตอนแรก
อ้างอิง: A safe pointer in C++ that protects against use after free and updates when the pointee is moved