Ngôn ngữ lập trình C++ đang đứng trước ngã tư khi cộng đồng phải vật lộn với những câu hỏi cơ bản về tính an toàn, khả năng tương thích ngược và hướng phát triển tương lai của ngôn ngữ. Trong khi C++26 giới thiệu erroneous behaviour để giải quyết việc đọc các biến chưa được khởi tạo, một cuộc tranh cãi lớn hơn đã nổi lên xung quanh cách ủy ban xử lý các đề xuất an toàn toàn diện.
C++26 Hành Vi Lỗi so với Các Phương Án Thay Thế
- Hiện Trạng ( C++23 ): Việc đọc dữ liệu chưa khởi tạo gây ra hành vi không xác định, chẩn đoán không đáng tin cậy
- Khởi Tạo Bằng Không: Có thể dự đoán được nhưng có khả năng che giấu lỗi, làm vô hiệu hóa các công cụ chẩn đoán
- Hành Vi Lỗi ( C++26 ): Hành vi không chính xác được định nghĩa rõ ràng, bảo toàn khả năng chẩn đoán
- Cơ Chế Loại Trừ: Thuộc tính [[indeterminate]] cho mã nguồn quan trọng về hiệu suất
Ủy ban chặn giải pháp an toàn toàn diện
Ủy ban tiêu chuẩn C++ đã từ chối một cách hiệu quả đề xuất Safe C++ của Sean Baxter , đề xuất này hứa hẹn mang lại tính an toàn bộ nhớ hoàn toàn trong khi vẫn duy trì khả năng tương thích ngược đầy đủ với mã nguồn hiện có. Đề xuất này, được hỗ trợ bởi một triển khai hoạt động có tên Circle , đại diện cho nhiều năm nỗ lực cá nhân nhằm giải quyết các vấn đề an toàn của C++ mà không phá vỡ các codebase hiện có. Việc từ chối diễn ra thông qua việc áp dụng các nguyên tắc thiết kế dường như đã loại trừ trước những cách tiếp cận như vậy, khiến nhiều người trong cộng đồng đặt câu hỏi về cam kết của ủy ban đối với những cải tiến an toàn có ý nghĩa.
Thời điểm của quyết định này đã gây ra cuộc tranh luận gay gắt, đặc biệt khi các ngôn ngữ khác như Rust tiếp tục chiếm được chỗ đứng trong các lĩnh vực lập trình hệ thống vốn được C++ thống trị truyền thống.
Lộ trình đề xuất Safe C++
- P3390R0: Đề xuất Safe C++ với triển khai Circle
- Cuộc họp Wrocław tháng 11-2024: Ủy ban bỏ phiếu về phương pháp Safe C++
- P3466 R1: Các nguyên tắc thiết kế được thông qua đã loại bỏ các giải pháp kiểu Safe C++
- Kết quả: Đề xuất an toàn toàn diện bị từ chối một cách hiệu quả
Tình thế tiến thoái lưỡng nan của khả năng tương thích ngược
Các cuộc thảo luận trong cộng đồng cho thấy sự thất vọng sâu sắc với cam kết không lay chuyển của C++ đối với khả năng tương thích ngược. Nhiều nhà phát triển cho rằng sự ám ảnh này ngăn cản ngôn ngữ giải quyết những khuyết điểm cơ bản đã làm phiền nó trong nhiều thập kỷ. Mâu thuẫn rất rõ ràng: các dự án cần thiết những tính năng an toàn hiện đại, nhưng ủy ban từ chối thực hiện những thay đổi phá vỡ có thể kích hoạt chúng.
Ủy ban thực sự đang làm hỏng tầm nhìn về một C++ tốt bằng cách từ chối phá vỡ khả năng tương thích ngược để sửa chữa các vấn đề cốt lõi. Tôi đang nói về các kiểu cơ bản, chuyển đổi ngầm định, khởi tạo, bộ tiền xử lý, hành vi không xác định / ill-formed NDR.
Một số người cho rằng mã nguồn thực sự cũ hiếm khi cần các tính năng ngôn ngữ tiên tiến, khiến lập luận về khả năng tương thích ngược trở nên kém thuyết phục hơn so với vẻ ngoài.
Thực tế ngành công nghiệp so với lý tưởng học thuật
Cuộc tranh luận mở rộng ra ngoài các cân nhắc kỹ thuật đến thực tế kinh tế. Các codebase lớn đại diện cho hàng tỷ đô la Mỹ chi phí phát triển không thể đơn giản được viết lại. Các công ty có các dự án C++ từ nhiều thập kỷ trước thấy mình bị mắc kẹt giữa nhu cầu cải thiện an toàn và sự bất khả thi của việc viết lại toàn bộ. Điều này tạo ra một hệ sinh thái phức tạp nơi những cải tiến từng bước như erroneous behaviour trở nên có giá trị, ngay cả khi chúng không đạt được các giải pháp toàn diện.
Trong khi đó, các dự án mới hơn ngày càng chọn các lựa chọn thay thế như Rust , ngôn ngữ cung cấp tính an toàn bộ nhớ theo thiết kế thay vì như một suy nghĩ sau.
Sở thích Ngôn ngữ Cộng đồng theo Trường hợp Sử dụng
- Codebase Cũ: Bị mắc kẹt với C++ do chi phí viết lại (hàng tỷ USD)
- Dự án Mới: Ngày càng lựa chọn Rust để đảm bảo an toàn bộ nhớ
- Phát triển Game: C++ vẫn thống trị với các engine Unreal , Godot
- Ứng dụng GUI: Qt cho C++ so với các lựa chọn thay thế Rust mới nổi như egui
- Yêu cầu Hiệu suất Cao: C++ với việc sử dụng tập con cẩn thận so với các khối unsafe của Rust
Mối quan tâm về hiệu suất và công cụ
Việc giới thiệu erroneous behaviour nhằm cung cấp kết quả có thể dự đoán cho việc đọc các biến chưa được khởi tạo trong khi vẫn duy trì khả năng chẩn đoán. Không giống như việc khởi tạo bằng zero đơn giản, cách tiếp cận này bảo tồn các công cụ gỡ lỗi hiện có giúp phát hiện những vấn đề này trong quá trình phát triển. Tuy nhiên, vẫn còn câu hỏi về tác động hiệu suất và liệu các nhà cung cấp compiler có thực sự triển khai các chẩn đoán được khuyến nghị một cách nhất quán hay không.
Thuộc tính [[indeterminate]] cung cấp một lối thoát cho mã nguồn quan trọng về hiệu suất có chủ ý sử dụng bộ nhớ chưa được khởi tạo, tuân theo nguyên tắc không trả tiền cho những gì bạn không sử dụng của C++ .
Nhìn về phía trước
Khi C++ tiếp tục phát triển với các bản phát hành được lên kế hoạch có thể mở rộng đến C++43 và xa hơn nữa, cộng đồng vẫn chia rẽ về việc liệu các cải tiến từng bước có thể giải quyết những thách thức cơ bản của ngôn ngữ hay không. Trong khi một số nhà phát triển đã chuyển sang các lựa chọn thay thế, những người khác tiếp tục làm việc trong các ràng buộc của C++ , hy vọng có những thay đổi đáng kể hơn trong các tiêu chuẩn tương lai.
Việc từ chối các đề xuất an toàn toàn diện cho thấy ủy ban vẫn cam kết với cách tiếp cận hiện tại, để lại câu hỏi rộng hơn về khả năng tồn tại lâu dài của C++ trong bối cảnh lập trình ngày càng quan tâm đến an toàn mà chưa được giải quyết.
Tham khảo: C++26: erroneous behaviour