Là == và! = Phụ thuộc lẫn nhau?

Tôi đang tìm hiểu về quá tải toán tử trong C ++ và tôi thấy điều đó ==và !=chỉ đơn giản là một số chức năng đặc biệt có thể được tùy chỉnh cho các loại do người dùng xác định. Tuy nhiên, mối quan tâm của tôi là tại sao có hai định nghĩa riêng biệt cần thiết? Tôi nghĩ rằng nếu a == blà đúng, thì a != btự động là sai, và ngược lại, và không có khả năng nào khác, bởi vì, theo định nghĩa, a != blà !(a == b). Và tôi không thể tưởng tượng bất kỳ tình huống nào trong đó không đúng. Nhưng có lẽ trí tưởng tượng của tôi bị hạn chế hoặc tôi không biết gì?

Tôi biết rằng tôi có thể định nghĩa cái này theo nghĩa khác, nhưng đây không phải là điều tôi đang hỏi. Tôi cũng không hỏi về sự khác biệt giữa so sánh các đối tượng theo giá trị hoặc theo danh tính. Hoặc liệu hai đối tượng có thể bằng nhau và không bằng nhau cùng một lúc hay không (đây chắc chắn không phải là một lựa chọn! Những thứ này là loại trừ lẫn nhau). Những gì tôi đang hỏi là đây:

Có bất kỳ tình huống nào có thể trong đó việc đặt câu hỏi về hai đối tượng bằng nhau có ý nghĩa gì không, nhưng hỏi về việc chúng không bằng nhau không có ý nghĩa gì? (theo quan điểm của người dùng hoặc quan điểm của người thực hiện)

Nếu không có khả năng như vậy, thì tại sao trên Trái đất, C ++ lại có hai toán tử này được định nghĩa là hai hàm riêng biệt?

Bạn sẽ không muốn ngôn ngữ tự động viết lại a != bnhư !(a == b)khi a == btrả về một thứ khác ngoàibool . Và có một vài lý do tại sao bạn có thể làm cho nó làm điều đó.

Bạn có thể có các đối tượng trình tạo biểu thức, trong a == bđó không và không có ý định thực hiện bất kỳ so sánh nào, nhưng chỉ cần xây dựng một số nút biểu thức đại diệna == b .

Bạn có thể lười đánh giá, trong a == bđó không và không có ý định thực hiện bất kỳ so sánh trực tiếp nào, nhưng thay vào đó trả về một số loại lazy<bool>có thể được chuyển đổi thành boolngầm hoặc rõ ràng vào một lúc nào đó để thực sự so sánh. Có thể kết hợp với các đối tượng xây dựng biểu thức để cho phép tối ưu hóa biểu thức hoàn chỉnh trước khi đánh giá.

Bạn có thể có một số optional<T>lớp mẫu tùy chỉnh , trong đó đưa ra các biến tùy chọn tvà u, bạn muốn cho phép t == u, nhưng làm cho nó trở lạioptional<bool> .

Có lẽ tôi còn nghĩ nhiều hơn thế. Và mặc dù trong các ví dụ này, hoạt động a == bvà a != bcả hai đều có ý nghĩa, nhưng vẫn a != bkhông giống như !(a == b)vậy, vì vậy cần có các định nghĩa riêng biệt.

Nếu không có khả năng như vậy, thì tại sao trên Trái đất, C ++ lại có hai toán tử này được định nghĩa là hai hàm riêng biệt?

Bởi vì bạn có thể quá tải chúng, và bằng cách quá tải chúng, bạn có thể mang đến cho chúng một ý nghĩa hoàn toàn khác với nghĩa gốc của chúng.

Lấy ví dụ, toán tử <<, ban đầu là toán tử dịch chuyển trái bit, giờ thường bị quá tải như một toán tử chèn, như trong std::cout << something; ý nghĩa hoàn toàn khác với bản gốc.

Vì vậy, nếu bạn chấp nhận rằng ý nghĩa của toán tử thay đổi khi bạn quá tải nó, thì không có lý do gì để ngăn người dùng đưa ra ý nghĩa cho toán tử ==không chính xác là phủ định của toán tử !=, mặc dù điều này có thể gây nhầm lẫn.

Tuy nhiên, mối quan tâm của tôi là tại sao có hai định nghĩa riêng biệt cần thiết?

Bạn không phải xác định cả hai.
Nếu chúng loại trừ lẫn nhau, bạn vẫn có thể súc tích bằng cách chỉ xác định ==và <bên cạnh std :: rel_ops

Fom cppreference:

#include <iostream>
#include <utility>

struct Foo {
    int n;
};

bool operator==(const Foo& lhs, const Foo& rhs)
{
    return lhs.n == rhs.n;
}

bool operator<(const Foo& lhs, const Foo& rhs)
{
    return lhs.n < rhs.n;
}

int main()
{
    Foo f1 = {1};
    Foo f2 = {2};
    using namespace std::rel_ops;

    //all work as you would expect
    std::cout << "not equal:     : " << (f1 != f2) << '\n';
    std::cout << "greater:       : " << (f1 > f2) << '\n';
    std::cout << "less equal:    : " << (f1 <= f2) << '\n';
    std::cout << "greater equal: : " << (f1 >= f2) << '\n';
}

Có bất kỳ tình huống nào có thể trong đó việc đặt câu hỏi về hai đối tượng bằng nhau có ý nghĩa gì không, nhưng hỏi về việc chúng không bằng nhau không có ý nghĩa gì?

Chúng tôi thường liên kết các nhà khai thác để bình đẳng.
Mặc dù đó là cách họ hành xử trên các loại cơ bản, nhưng không có nghĩa vụ rằng đây là hành vi của họ đối với các loại dữ liệu tùy chỉnh. Bạn thậm chí không phải trả lại một bool nếu bạn không muốn.

Tôi đã thấy mọi người quá tải các nhà khai thác theo những cách kỳ quái, chỉ để thấy rằng nó có ý nghĩa đối với ứng dụng cụ thể miền của họ. Ngay cả khi giao diện xuất hiện cho thấy chúng là loại trừ lẫn nhau, tác giả có thể muốn thêm logic bên trong cụ thể.

(theo quan điểm của người dùng hoặc quan điểm của người thực hiện)

Tôi biết bạn muốn có một ví dụ cụ thể,
vì vậy đây là một ví dụ từ khung thử nghiệm Catch mà tôi nghĩ là thiết thực:

template<typename RhsT>
ResultBuilder& operator == ( RhsT const& rhs ) {
    return captureExpression<Internal::IsEqualTo>( rhs );
}

template<typename RhsT>
ResultBuilder& operator != ( RhsT const& rhs ) {
    return captureExpression<Internal::IsNotEqualTo>( rhs );
}

Các toán tử này đang làm những việc khác nhau và sẽ không có nghĩa gì khi định nghĩa một phương thức này là một (không phải) của phương thức kia. Lý do này được thực hiện, là để khung có thể in ra so sánh được thực hiện. Để làm điều đó, nó cần phải nắm bắt bối cảnh của toán tử quá tải đã được sử dụng.

Có một số công ước rất tốt được thành lập trong đó (a == b)và (a != b)là cả hai giả không nhất thiết đối lập. Cụ thể, trong SQL, mọi so sánh với NULL đều mang lại NULL, không đúng hoặc sai.

Có lẽ không nên tạo ra các ví dụ mới về điều này nếu có thể, bởi vì nó không trực quan, nhưng nếu bạn đang cố gắng mô hình hóa một quy ước hiện có, thật tốt khi có tùy chọn để các nhà khai thác của bạn hành xử "chính xác" cho điều đó bối cảnh.

Tôi sẽ chỉ trả lời phần thứ hai của câu hỏi của bạn, cụ thể là:

Nếu không có khả năng như vậy, thì tại sao trên Trái đất, C ++ lại có hai toán tử này được định nghĩa là hai hàm riêng biệt?

Một lý do tại sao nó có ý nghĩa để cho phép nhà phát triển quá tải cả hai là hiệu suất. Bạn có thể cho phép tối ưu hóa bằng cách thực hiện cả hai ==và !=. Sau đó x != ycó thể rẻ hơn!(x == y) là. Một số trình biên dịch có thể tối ưu hóa nó cho bạn, nhưng có lẽ là không, đặc biệt là nếu bạn có các đối tượng phức tạp với nhiều nhánh liên quan.

Ngay cả ở Haskell, nơi các nhà phát triển rất coi trọng luật pháp và các khái niệm toán học, người ta vẫn được phép quá tải cả hai ==và /=, như bạn có thể thấy ở đây ( http://hackage.haskell.org/package/base-4.9.0.0/docs/Prelude .html # v: -61--61- ):

$ ghci
GHCi, version 7.10.2: http://www.haskell.org/ghc/  :? for help
λ> :i Eq
class Eq a where
  (==) :: a -> a -> Bool
  (/=) :: a -> a -> Bool
        -- Defined in `GHC.Classes'

Điều này có thể được coi là tối ưu hóa vi mô, nhưng nó có thể được bảo hành cho một số trường hợp.

Có bất kỳ tình huống nào có thể trong đó việc đặt câu hỏi về hai đối tượng bằng nhau có ý nghĩa gì không, nhưng hỏi về việc chúng không bằng nhau không có ý nghĩa gì? (theo quan điểm của người dùng hoặc quan điểm của người thực hiện)

Đó là một ý kiến. Có lẽ nó không. Nhưng các nhà thiết kế ngôn ngữ, không phải là người toàn diện, đã quyết định không hạn chế những người có thể đưa ra các tình huống có thể có ý nghĩa (ít nhất là với họ).

Để đáp ứng với chỉnh sửa;

Đó là, nếu một số loại có thể có toán tử ==nhưng không phải !=, hoặc ngược lại, và khi nào thì có ý nghĩa để làm như vậy.

Nói chung , không, nó không có ý nghĩa. Các toán tử bình đẳng và quan hệ thường đi theo bộ. Nếu có sự bình đẳng, thì bất bình đẳng là tốt; ít hơn, sau đó lớn hơn và như vậy với<= v.v. Một cách tiếp cận tương tự cũng được áp dụng cho các toán tử số học, chúng cũng thường đi kèm trong các tập hợp logic tự nhiên.

Điều này được chứng minh trong std::rel_ops không gian tên. Nếu bạn thực hiện sự bình đẳng và ít hơn các toán tử, sử dụng không gian tên đó mang lại cho bạn các toán tử khác, được triển khai theo các toán tử được triển khai ban đầu của bạn.

Tất cả đã nói, có những điều kiện hoặc tình huống mà cái này không có nghĩa là cái kia ngay lập tức, hoặc không thể được thực hiện theo nghĩa của những cái khác? Vâng, có rất ít, nhưng chúng ở đó; một lần nữa, như đã chứng minh trongrel_ops là không gian tên của chính nó. Vì lý do đó, cho phép chúng được triển khai độc lập cho phép bạn tận dụng ngôn ngữ để có được ngữ nghĩa mà bạn yêu cầu hoặc cần theo cách vẫn tự nhiên và trực quan cho người dùng hoặc khách hàng của mã.

Đánh giá lười biếng đã được đề cập là một ví dụ tuyệt vời về điều này. Một ví dụ điển hình khác là cung cấp cho họ ngữ nghĩa không có nghĩa là bình đẳng hoặc không bình đẳng. Một ví dụ tương tự như vậy là các toán tử dịch chuyển bit <<và >>được sử dụng để chèn và trích xuất luồng. Mặc dù nó có thể được tán thành trong các vòng tròn nói chung, trong một số lĩnh vực cụ thể của miền, nó có thể có ý nghĩa.

Nếu các toán tử ==và !=toán tử không thực sự ngụ ý sự bình đẳng, theo cùng một cách mà các toán tử luồng <<và >>luồng không ngụ ý dịch chuyển bit. Nếu bạn coi các biểu tượng như thể chúng có nghĩa là một số khái niệm khác, thì chúng không phải loại trừ lẫn nhau.

Về mặt bình đẳng, sẽ có ý nghĩa nếu trường hợp sử dụng của bạn đảm bảo coi các đối tượng là không thể so sánh, do đó mọi so sánh sẽ trả về sai (hoặc loại kết quả không thể so sánh, nếu toán tử của bạn trả về giá trị không phải là bool). Tôi không thể nghĩ đến một tình huống cụ thể nơi điều này sẽ được bảo hành, nhưng tôi có thể thấy nó đủ hợp lý.

Với sức mạnh tuyệt vời đến rất có trách nhiệm, hoặc ít nhất là hướng dẫn phong cách thực sự tốt.

==và !=có thể bị quá tải để làm bất cứ điều gì bạn muốn. Đó là cả một phước lành và một lời nguyền. Không có gì đảm bảo điều đó !=có nghĩa !(a==b).

enum BoolPlus {
    kFalse = 0,
    kTrue = 1,
    kFileNotFound = -1
}

BoolPlus operator==(File& other);
BoolPlus operator!=(File& other);

Tôi không thể biện minh cho việc quá tải toán tử này, nhưng trong ví dụ trên, không thể định nghĩa operator!=là "đối diện" của operator==.

Cuối cùng, điều bạn đang kiểm tra với các toán tử đó là biểu thức a == b hoặc a != bđang trả về giá trị Boolean ( truehoặc false). Các biểu thức này trả về giá trị Boolean sau khi so sánh thay vì loại trừ lẫn nhau.

[..] tại sao có hai định nghĩa riêng biệt cần thiết?

Một điều cần xem xét là có thể có khả năng thực hiện một trong những toán tử này hiệu quả hơn là chỉ sử dụng phủ định của cái kia.

(Ví dụ của tôi ở đây là rác rưởi, nhưng vấn đề vẫn còn tồn tại, hãy nghĩ đến các bộ lọc nở, ví dụ: Chúng cho phép thử nghiệm nhanh nếu có thứ gì đó không có trong một bộ, nhưng thử nghiệm nếu nó có thể mất nhiều thời gian hơn.)

[..] theo định nghĩa, a != blà !(a == b).

Và trách nhiệm của bạn là lập trình viên để thực hiện điều đó. Có lẽ là một điều tốt để viết một bài kiểm tra cho.

Bằng cách tùy chỉnh hành vi của các nhà khai thác, bạn có thể khiến họ làm những gì bạn muốn.

Bạn có thể muốn tùy chỉnh mọi thứ. Ví dụ, bạn có thể muốn tùy chỉnh một lớp. Các đối tượng của lớp này có thể được so sánh chỉ bằng cách kiểm tra một thuộc tính cụ thể. Biết rằng đây là trường hợp, bạn có thể viết một số mã cụ thể chỉ kiểm tra những thứ tối thiểu, thay vì kiểm tra từng bit của mỗi thuộc tính trong toàn bộ đối tượng.

Hãy tưởng tượng một trường hợp mà bạn có thể nhận ra rằng một cái gì đó khác biệt cũng nhanh như vậy, nếu không nhanh hơn, bạn có thể tìm ra thứ gì đó giống nhau. Cấp, một khi bạn tìm ra liệu một cái gì đó giống hay khác nhau, thì bạn có thể biết điều ngược lại chỉ bằng cách lật một chút. Tuy nhiên, lật bit đó là một hoạt động bổ sung. Trong một số trường hợp, khi mã được thực thi lại rất nhiều, việc lưu một thao tác (nhân với nhiều lần) có thể có tốc độ tăng tổng thể. (Ví dụ: nếu bạn lưu một thao tác trên mỗi pixel của màn hình megapixel, thì bạn vừa lưu một triệu thao tác. Nhân với 60 màn hình mỗi giây và bạn còn tiết kiệm được nhiều thao tác hơn nữa.)

câu trả lời của hvd cung cấp một số ví dụ bổ sung.

Có, bởi vì một nghĩa là "tương đương" và một nghĩa khác là "không tương đương" và các thuật ngữ này loại trừ lẫn nhau. Bất kỳ ý nghĩa nào khác cho toán tử này là khó hiểu và nên tránh bằng mọi cách.

Có lẽ một quy tắc uncomparable, nơi a != bđã sai và a == bđã sai như một chút không quốc tịch.

if( !(a == b || a != b) ){
    // Stateless
}