Tại sao bất đẳng thức được kiểm tra là (! (A == b)) trong rất nhiều mã thư viện chuẩn C ++?

Đây là mã từ removemã thư viện chuẩn C ++ . Tại sao bất đẳng thức được kiểm tra if (!(*first == val))thay vì if (*first != val)?

 template <class ForwardIterator, class T>
      ForwardIterator remove (ForwardIterator first, ForwardIterator last, const T& val)
 {
     ForwardIterator result = first;
     while (first!=last) {
         if (!(*first == val)) {
             *result = *first;
             ++result;
         }
         ++first;
     }
     return result;
 }

Bởi vì điều này có nghĩa là yêu cầu duy nhất trên T là thực hiện một operator==. Bạn có thể yêu cầu T phải có một operator!=ý tưởng chung nhưng ở đây là bạn nên đặt càng ít gánh nặng cho người dùng mẫu càng tốt và các mẫu khác cần operator==.

Hầu hết các chức năng trong STL chỉ hoạt động với operator<hoặc operator==. Điều này yêu cầu người dùng chỉ thực hiện hai toán tử này (hoặc đôi khi ít nhất một trong số họ). Ví dụ std::setsử dụng operator<(chính xác hơn std::lessmà gọioperator< theo mặc định) và không operator>quản lý đơn hàng. Các removemẫu trong ví dụ của bạn là một trường hợp tương tự - nó chỉ sử dụng operator==và không operator!=nên operator!=không cần phải được xác định.

Đây là mã từ thư viện tiêu chuẩn C ++ loại bỏ mã.

Sai lầm. Đây không phải làremove mã thư viện chuẩn C ++ . Đây là một khả năng thực hiện bên trong của removechức năng thư viện chuẩn C ++ . Tiêu chuẩn C ++ không quy định mã thực tế; nó đặt trước các nguyên mẫu chức năng và các hành vi cần thiết.

Nói cách khác: Từ quan điểm ngôn ngữ nghiêm ngặt, mã bạn đang thấy không tồn tại . Nó có thể là từ một số tệp tiêu đề đi kèm với việc triển khai thư viện chuẩn của trình biên dịch của bạn. Lưu ý rằng tiêu chuẩn C ++ thậm chí không yêu cầu các tệp tiêu đề đó tồn tại. Các tệp chỉ là một cách thuận tiện cho người triển khai trình biên dịch để đáp ứng các yêu cầu cho một dòng như #include <algorithm>(nghĩa là tạo std::removevà các chức năng khác có sẵn).

Tại sao bất đẳng thức được kiểm tra if (!(*first == val))thay vì if (*first != val)?

Bởi vì chỉ operator==được yêu cầu bởi chức năng.

Khi nói đến quá tải toán tử cho các loại tùy chỉnh, ngôn ngữ cho phép bạn thực hiện tất cả các loại điều kỳ lạ. Bạn rất có thể tạo ra một lớp có quá tải operator==nhưng không quá tải operator!=. Hoặc thậm chí tệ hơn: Bạn có thể quá tải operator!=nhưng để nó làm những việc hoàn toàn không liên quan.

Xem xét ví dụ này:

#include <algorithm>
#include <vector>

struct Example
{
    int i;

    Example() : i(0) {}

    bool operator==(Example const& other) const
    {
        return i == other.i;
    }

    bool operator!=(Example const& other) const
    {
        return i == 5; // weird, but nothing stops you
                       // from doing so
    }

};

int main()
{
  std::vector<Example> v(10);
  // ...
  auto it = std::remove(v.begin(), v.end(), Example());
  // ...
}

Nếu std::removeđược sử dụng operator!=, thì kết quả sẽ khá khác nhau.

Một số câu trả lời tốt ở đây. Tôi chỉ muốn thêm một chút lưu ý.

Giống như tất cả các thư viện tốt, thư viện chuẩn được thiết kế với (ít nhất) hai nguyên tắc rất quan trọng:

1. Đặt ít trách nhiệm nhất cho người dùng thư viện của bạn mà bạn có thể thoát khỏi. Một phần của điều này có liên quan đến việc cung cấp cho họ ít công việc nhất phải làm khi sử dụng giao diện của bạn. (giống như xác định ít toán tử như bạn có thể thoát khỏi). Phần khác của nó phải làm với việc không làm họ ngạc nhiên hoặc yêu cầu họ kiểm tra mã lỗi (vì vậy hãy giữ giao diện nhất quán và ném ngoại lệ <stdexcept>khi có sự cố).

2. Loại bỏ tất cả sự dư thừa hợp lý . Tất cả các so sánh có thể được suy luận chỉ từ operator<, vậy tại sao nhu cầu người dùng định nghĩa người khác? ví dụ:

   (a> b) tương đương với (b <a)

   (a> = b) tương đương với! (a <b)

   (a == b) tương đương với! ((a <b) || (b <a))

   và như thế.

   Tất nhiên trên lưu ý này, người ta có thể hỏi tại sao unordered_mapyêu cầu operator==(ít nhất là theo mặc định) chứ không phải operator<. Câu trả lời là trong một bảng băm, sự so sánh duy nhất chúng ta từng yêu cầu là một sự bình đẳng. Do đó, nó phù hợp hơn về mặt logic (nghĩa là có ý nghĩa hơn đối với người dùng thư viện) để yêu cầu họ xác định một toán tử đẳng thức. Yêu cầu một điều operator<sẽ gây nhầm lẫn bởi vì nó không rõ ràng ngay lập tức tại sao bạn cần nó.

Các EqualityComparablekhái niệm chỉ yêu cầu operator==được xác định.

Do đó, bất kỳ chức năng nào tuyên bố làm việc với các loại thỏa mãn EqualityComparable đều không thể dựa vào sự tồn tại của operator!=các đối tượng thuộc loại đó. (trừ khi có các yêu cầu bổ sung ngụ ý sự tồn tại của operator!=).

Cách tiếp cận hứa hẹn nhất là tìm một phương pháp xác định xem toán tử == có thể được gọi cho một loại cụ thể hay không, và sau đó chỉ hỗ trợ nó khi có sẵn; trong các tình huống khác, một ngoại lệ sẽ được ném ra. Tuy nhiên, cho đến nay không có cách nào để phát hiện nếu một biểu thức toán tử tùy ý f == g được xác định phù hợp. Giải pháp tốt nhất được biết có những phẩm chất không mong muốn sau:

• Thất bại tại thời gian biên dịch cho các đối tượng mà toán tử == không truy cập được (ví dụ: vì nó là riêng tư).
• Thất bại tại thời gian biên dịch nếu gọi toán tử == là không rõ ràng.
• Xuất hiện là chính xác nếu toán tử == khai báo là đúng, mặc dù toán tử == có thể không biên dịch.

Từ Boost FAQ: nguồn

Biết rằng yêu cầu ==thực hiện là một gánh nặng , bạn không bao giờ muốn tạo thêm gánh nặng bằng cách yêu cầu!= thực hiện là tốt.

Đối với cá nhân tôi, đó là về phần RẮN (thiết kế hướng đối tượng) Phần L - Nguyên tắc thay thế Liskov: Các đối tượng trong một chương trình nên có thể thay thế bằng các thể hiện của các kiểu con của chúng mà không làm thay đổi tính chính xác của chương trình đó. Trong trường hợp này, nó là toán tử ! = Mà tôi có thể thay thế bằng == và nghịch đảo boolean trong logic boolean.