Tại sao trình biên dịch C ++ không định nghĩa toán tử == và toán tử! =?

Tôi là một fan hâm mộ lớn của việc để trình biên dịch làm nhiều việc cho bạn nhất có thể. Khi viết một lớp đơn giản, trình biên dịch có thể cung cấp cho bạn những thứ sau đây là 'miễn phí':

• Một constructor mặc định (trống)
• Một constructor sao chép
• Một kẻ hủy diệt
• Một toán tử gán ( operator=)

Nhưng nó dường như không thể cung cấp cho bạn bất kỳ toán tử so sánh nào - chẳng hạn như operator==hoặc operator!=. Ví dụ:

class foo
{
public:
    std::string str_;
    int n_;
};

foo f1;        // Works
foo f2(f1);    // Works
foo f3;
f3 = f2;       // Works

if (f3 == f2)  // Fails
{ }

if (f3 != f2)  // Fails
{ }

Có một lý do tốt cho việc này? Tại sao thực hiện so sánh giữa các thành viên là một vấn đề? Rõ ràng nếu lớp phân bổ bộ nhớ thì bạn muốn cẩn thận, nhưng đối với một lớp đơn giản chắc chắn trình biên dịch có thể làm điều này cho bạn?

Trình biên dịch sẽ không biết bạn muốn so sánh con trỏ hay so sánh sâu (bên trong).

An toàn hơn là không thực hiện nó và để cho lập trình viên tự làm điều đó. Sau đó, họ có thể thực hiện tất cả các giả định mà họ thích.

Đối số nếu trình biên dịch có thể cung cấp một hàm tạo sao chép mặc định, thì nó có thể cung cấp một mặc định tương tự operator==()có ý nghĩa nhất định. Tôi nghĩ rằng lý do cho quyết định không cung cấp mặc định do trình biên dịch tạo cho toán tử này có thể được đoán bởi những gì Stroustrup nói về hàm tạo sao chép mặc định trong "Thiết kế và tiến hóa của C ++" (Phần 11.4.1 - Kiểm soát sao chép) :

Cá nhân tôi cho rằng thật đáng tiếc rằng các hoạt động sao chép được xác định theo mặc định và tôi cấm sao chép các đối tượng của nhiều lớp của tôi. Tuy nhiên, C ++ thừa hưởng các hàm tạo và gán sao chép mặc định từ C và chúng thường được sử dụng.

Vì vậy, thay vì "tại sao C ++ không có mặc định operator==()?", Câu hỏi nên là "tại sao C ++ có hàm gán và sao chép mặc định?", Với câu trả lời là các mục đó được Stroustrup đưa vào một cách miễn cưỡng để tương thích ngược với C (có lẽ là nguyên nhân của hầu hết các mụn cóc của C ++, nhưng cũng có thể là lý do chính cho sự phổ biến của C ++).

Đối với mục đích riêng của tôi, trong IDE của tôi, đoạn mã tôi sử dụng cho các lớp mới chứa các khai báo cho một toán tử gán riêng và hàm tạo sao chép để khi tôi tạo một lớp mới, tôi không nhận được các thao tác sao chép và gán mặc định - Tôi phải loại bỏ khai báo một cách rõ ràng trong số các hoạt động từ private:phần đó nếu tôi muốn trình biên dịch có thể tạo chúng cho tôi.

Ngay cả trong C ++ 20, trình biên dịch vẫn sẽ không tạo ra operator==cho bạn

struct foo
{
    std::string str;
    int n;
};

assert(foo{"Anton", 1} == foo{"Anton", 1}); // ill-formed

Nhưng bạn sẽ có được khả năng mặc định rõ ràng == kể từ C ++ 20 :

struct foo
{
    std::string str;
    int n;

    // either member form
    bool operator==(foo const&) const = default;
    // ... or friend form
    friend bool operator==(foo const&, foo const&) = default;
};

Mặc định ==thực hiện thành viên khôn ngoan ==(giống như cách mà trình xây dựng sao chép mặc định thực hiện xây dựng sao chép thành viên khôn ngoan). Các quy tắc mới cũng cung cấp mối quan hệ mong đợi giữa ==và !=. Ví dụ, với khai báo ở trên, tôi có thể viết cả hai:

assert(foo{"Anton", 1} == foo{"Anton", 1}); // ok!
assert(foo{"Anton", 1} != foo{"Anton", 2}); // ok!

Tính năng cụ thể này (mặc định operator==và đối xứng giữa ==và !=) xuất phát từ một đề xuất là một phần của tính năng ngôn ngữ rộng hơn operator<=>.

IMHO, không có lý do "tốt". Lý do có rất nhiều người đồng ý với quyết định thiết kế này là vì họ không học cách làm chủ sức mạnh của ngữ nghĩa dựa trên giá trị. Mọi người cần phải viết rất nhiều hàm tạo sao chép tùy chỉnh, toán tử so sánh và hàm hủy vì chúng sử dụng các con trỏ thô trong quá trình thực hiện.

Khi sử dụng các con trỏ thông minh thích hợp (như std :: shared_ptr), hàm tạo sao chép mặc định thường ổn và việc triển khai rõ ràng của toán tử so sánh mặc định giả định sẽ tốt.

Nó đã trả lời C ++ không làm == vì C không có, và đây là lý do tại sao C chỉ cung cấp mặc định = nhưng không == ở vị trí đầu tiên. C muốn giữ cho nó đơn giản: C thực hiện = bởi memcpy; tuy nhiên, == không thể được thực hiện bởi memcmp do phần đệm. Vì phần đệm không được khởi tạo, memcmp nói rằng chúng khác nhau mặc dù chúng giống nhau. Vấn đề tương tự tồn tại đối với lớp trống: memcmp nói rằng chúng khác nhau vì kích thước của các lớp trống không bằng không. Có thể thấy từ trên rằng việc triển khai == phức tạp hơn so với triển khai = trong C. Một số ví dụ mã liên quan đến việc này. Sửa chữa của bạn được đánh giá cao nếu tôi sai.

Trong video này Alex Stepanov, người tạo ra STL giải quyết câu hỏi này vào khoảng 13:00. Tóm lại, khi theo dõi sự phát triển của C ++, ông lập luận rằng:

• Thật không may rằng == và! = Không được tuyên bố ngầm (và Bjarne đồng ý với anh ta). Một ngôn ngữ chính xác sẽ có sẵn những điều đó cho bạn (anh ấy tiếp tục đề xuất rằng bạn không thể xác định a ! = Điều đó phá vỡ ngữ nghĩa của == )
• Lý do đây là trường hợp có nguồn gốc của nó (như nhiều vấn đề về C ++) trong C. Ở đó, toán tử gán được định nghĩa ngầm định bằng bit by bit gán nhưng điều đó sẽ không hoạt động cho == . Một lời giải thích chi tiết hơn có thể được tìm thấy trong bài viết này từ Bjarne Stroustrup.
• Trong câu hỏi tiếp theo Tại sao khi đó không phải là thành viên do so sánh thành viên sử dụng , anh ta nói một điều đáng kinh ngạc : C là một ngôn ngữ trong nhà và anh chàng thực hiện những thứ này cho Ritchie nói với anh rằng anh ta thấy điều này khó thực hiện!

Sau đó, ông nói rằng trong tương lai (xa) == và ! = Sẽ được tạo ngầm.

C ++ 20 cung cấp một cách để dễ dàng thực hiện một toán tử so sánh mặc định.

Ví dụ từ cppreference.com :

class Point {
    int x;
    int y;
public:
    auto operator<=>(const Point&) const = default;
    // ... non-comparison functions ...
};

// compiler implicitly declares operator== and all four relational operators work
Point pt1, pt2;
if (pt1 == pt2) { /*...*/ } // ok, calls implicit Point::operator==
std::set<Point> s; // ok
s.insert(pt1); // ok
if (pt1 <= pt2) { /*...*/ } // ok, makes only a single call to Point::operator<=>

Không thể xác định mặc định ==, nhưng bạn có thể xác định mặc định !=thông qua ==đó bạn thường nên tự xác định. Đối với điều này, bạn nên làm những điều sau đây:

#include <utility>
using namespace std::rel_ops;
...

class FooClass
{
public:
  bool operator== (const FooClass& other) const {
  // ...
  }
};

Bạn có thể xem http://www.cplusplus.com/reference/std/utility/rel_ops/ để biết chi tiết.

Ngoài ra, nếu bạn xác định operator< , các toán tử cho <=,>,> = có thể được suy ra từ nó khi sử dụng std::rel_ops.

Nhưng bạn nên cẩn thận khi sử dụng std::rel_opsvì các toán tử so sánh có thể được suy ra cho các loại bạn không mong đợi.

Cách ưa thích hơn để suy ra toán tử liên quan từ cơ bản là sử dụng toán tử boost :: .

Cách tiếp cận được sử dụng trong boost là tốt hơn bởi vì nó xác định việc sử dụng toán tử cho lớp bạn chỉ muốn, không phải cho tất cả các lớp trong phạm vi.

Bạn cũng có thể tạo "+" từ "+ =", - từ "- =", v.v ... (xem danh sách đầy đủ tại đây )

C ++ 0x đã có một đề xuất cho các chức năng mặc định, vì vậy bạn có thể nói rằng default operator==; chúng tôi đã học được rằng nó giúp làm cho những điều này rõ ràng.

Về mặt khái niệm không dễ để xác định sự bình đẳng. Ngay cả đối với dữ liệu POD, người ta có thể lập luận rằng ngay cả khi các trường giống nhau, nhưng nó là một đối tượng khác nhau (tại một địa chỉ khác), nó không nhất thiết phải bằng nhau. Điều này thực sự phụ thuộc vào cách sử dụng của các nhà điều hành. Thật không may, trình biên dịch của bạn không phải là ngoại cảm và không thể suy ra điều đó.

Bên cạnh đó, các chức năng mặc định là những cách tuyệt vời để tự bắn vào chân mình. Mặc định bạn mô tả về cơ bản là ở đó để giữ khả năng tương thích với các cấu trúc POD. Tuy nhiên, chúng gây ra quá nhiều sự tàn phá với các nhà phát triển mà quên chúng hoặc ngữ nghĩa của các triển khai mặc định.

Có một lý do tốt cho việc này? Tại sao thực hiện so sánh giữa các thành viên là một vấn đề?

Nó có thể không phải là một vấn đề chức năng, nhưng về mặt hiệu suất, so sánh giữa các thành viên mặc định có thể được tối ưu hóa hơn so với phân công / sao chép thành viên mặc định. Không giống như thứ tự chuyển nhượng, thứ tự so sánh ảnh hưởng đến hiệu suất vì thành viên bất bình đẳng đầu tiên ngụ ý phần còn lại có thể được bỏ qua. Vì vậy, nếu có một số thành viên thường bằng nhau, bạn muốn so sánh họ lần cuối và trình biên dịch không biết thành viên nào có nhiều khả năng bằng nhau.

Xem xét ví dụ này, nơi verboseDescriptionmột chuỗi dài được chọn từ một tập hợp các mô tả thời tiết có thể tương đối nhỏ.

class LocalWeatherRecord {
    std::string verboseDescription;
    std::tm date;
    bool operator==(const LocalWeatherRecord& other){
        return date==other.date
            && verboseDescription==other.verboseDescription;
    // The above makes a lot more sense than
     // return verboseDescription==other.verboseDescription
     //     && date==other.date;
    // because some verboseDescriptions are liable to be same/similar
    }
}

(Tất nhiên trình biên dịch sẽ có quyền bỏ qua thứ tự so sánh nếu nó nhận ra rằng chúng không có tác dụng phụ, nhưng có lẽ nó vẫn sẽ lấy hàng đợi từ mã nguồn nơi nó không có thông tin tốt hơn.)

Để câu trả lời cho câu hỏi này vẫn hoàn thành khi thời gian trôi qua: vì C ++ 20, nó có thể được tạo tự động bằng lệnh auto operator<=>(const foo&) const = default;

Nó sẽ tạo ra tất cả các toán tử: == ,! =, <, <=,> Và> =, xem https://en.cppreference.com/w/cpp/lingu/default_comparisons để biết chi tiết.

Do cái nhìn của người vận hành <=>, nó được gọi là toán tử tàu vũ trụ. Xem thêm Tại sao chúng ta cần toán tử tàu vũ trụ <=> trong C ++? .

EDIT: cũng trong C ++ 11, một thay thế khá gọn gàng có sẵn với std::tiexem https://en.cppreference.com/w/cpp/utility/tuple/tie để biết ví dụ mã hoàn chỉnh với bool operator<(…). Phần thú vị, được thay đổi để làm việc với ==là:

#include <tuple>

struct S {
………
bool operator==(const S& rhs) const
    {
        // compares n to rhs.n,
        // then s to rhs.s,
        // then d to rhs.d
        return std::tie(n, s, d) == std::tie(rhs.n, rhs.s, rhs.d);
    }
};

std::tie hoạt động với tất cả các toán tử so sánh và được trình biên dịch hoàn toàn tối ưu hóa.

Tôi đồng ý, đối với các lớp loại POD thì trình biên dịch có thể làm điều đó cho bạn. Tuy nhiên những gì bạn có thể coi đơn giản là trình biên dịch có thể bị sai. Vì vậy, tốt hơn là để cho các lập trình viên làm điều đó.

Tôi đã có trường hợp POD một lần khi hai trong số các trường là duy nhất - vì vậy một so sánh sẽ không bao giờ được coi là đúng. Tuy nhiên, so sánh tôi chỉ cần so sánh về tải trọng - thứ mà trình biên dịch sẽ không bao giờ hiểu hoặc có thể tự mình tìm ra.

Bên cạnh đó - họ không mất nhiều thời gian để viết phải không?!