Tại sao std :: ssize () được giới thiệu trong C ++ 20?

C ++ 20 đã giới thiệu std::ssize()hàm miễn phí như sau:

template <class C>
    constexpr auto ssize(const C& c)
        -> std::common_type_t<std::ptrdiff_t,
                              std::make_signed_t<decltype(c.size())>>;

Một triển khai khả thi dường như sử dụng static_cast, để chuyển đổi giá trị trả về của size()hàm thành viên của cl ass C thành đối tác có dấu của nó.

Vì size()hàm thành viên của C luôn trả về các giá trị không âm, tại sao mọi người lại muốn lưu trữ chúng trong các biến có dấu? Trong trường hợp một người thực sự muốn, đó là một vấn đề đơn giản static_cast.

Tại sao lại được std::ssize()giới thiệu trong C ++ 20?

Cơ sở lý luận được mô tả trong bài báo này . Một câu trích dẫn:

Khi span được áp dụng vào C ++ 17, nó đã sử dụng một số nguyên có dấu cả làm chỉ mục và kích thước. Một phần là điều này cho phép sử dụng "-1" làm giá trị sentinel để chỉ ra một kiểu mà kích thước của nó không được biết tại thời điểm biên dịch. Nhưng có một vùng chứa STL có hàm size () trả về giá trị có dấu là vấn đề, vì vậy P1089 đã được giới thiệu để "khắc phục" sự cố. Nó nhận được sự ủng hộ của đa số, nhưng không phải là tỷ lệ chênh lệch 2 ăn 1 cần thiết cho sự đồng thuận.

Bài báo này, P1227, là một đề xuất để thêm các hàm std :: ssize và thành viên ssize () không phải thành viên. Việc bao gồm những điều này sẽ làm cho một số mã đơn giản hơn nhiều và cho phép tránh được các tính toán kích thước không mong muốn không mong muốn. Ý tưởng là khả năng chống lại P1089 sẽ giảm nếu ssize () có sẵn cho tất cả các vùng chứa, cả thông qua std :: ssize () và dưới dạng các hàm thành viên.

Bị đánh cắp một cách vô cớ từ Eric Niebler:

'Unsigned types signal that a negative index/size is not sane'là sự khôn ngoan thịnh hành khi STL được thiết kế lần đầu tiên. Nhưng về mặt logic, số lượng mọi thứ không cần phải tích cực. Tôi có thể muốn giữ số lượng ở dạng số nguyên có dấu để biểu thị số phần tử được thêm vào hoặc bị xóa khỏi tập hợp. Sau đó, tôi muốn kết hợp điều đó với kích thước của bộ sưu tập. Nếu kích thước của bộ sưu tập không có dấu, bây giờ tôi buộc phải kết hợp số học có dấu và không dấu, đó là một trang trại lỗi. Các trình biên dịch cảnh báo về điều này, nhưng vì thiết kế của STL khá nhiều buộc các lập trình viên vào tình huống này, cảnh báo này rất phổ biến nên hầu hết mọi người đều tắt nó đi. Thật đáng tiếc vì điều này ẩn chứa những lỗi thực sự.

Việc sử dụng int không dấu trong giao diện không phải là lợi ích mà nhiều người nghĩ. Nếu tình cờ một người dùng chuyển một số âm đến API, nó sẽ đột nhiên trở thành một số dương rất lớn. Nếu API lấy số như đã ký, thì nó có thể phát hiện tình huống bằng cách xác nhận số lớn hơn hoặc bằng không.

Nếu chúng ta hạn chế việc sử dụng các int không có dấu để làm lộn xộn (ví dụ: mặt nạ) và sử dụng các int có dấu ở mọi nơi khác, thì các lỗi sẽ ít xảy ra hơn và dễ dàng phát hiện hơn khi chúng xảy ra.