Чому компілятори C ++ не визначають operator == та operator! =?

Я великий фанат, щоб дозволити компілятору зробити якомога більше роботи за вас. Коли ви пишете простий клас, компілятор може дати вам наступне для "безкоштовно":

• Конструктор за замовчуванням (порожній)
• Конструктор копій
• Руйнівник
• Оператор призначення ( operator=)

Але це, здається, не дає вам порівняльних операторів - таких як operator==або operator!=. Наприклад:

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
{ }

Чи є для цього вагома причина? Чому проведення порівняння по одному члену може бути проблемою? Очевидно, якщо клас виділяє пам'ять, то ви хочете бути обережними, але для простого класу напевно компілятор міг би це зробити для вас?

Компілятор не знав, чи хочете ви порівняння вказівника чи глибокого (внутрішнього) порівняння.

Безпечніше просто не реалізувати це, а дозволити програмісту зробити це самостійно. Тоді вони можуть зробити всі припущення, які їм подобаються.

Аргумент того, що якщо компілятор може надати конструктор копій за замовчуванням, він повинен бути в змозі надати аналогічний за замовчуванням operator==()має певний сенс. Я думаю, що про причину рішення не надавати компілятор, створений компілятором для цього оператора, можна здогадатися, що Stroustrup сказав про конструктор копій за замовчуванням у "Дизайн та еволюція C ++" (Розділ 11.4.1 - Контроль копіювання) :

Особисто я вважаю прикро, що операції з копіюванням визначені за замовчуванням, і я забороняю копіювати об'єкти багатьох моїх класів. Однак C ++ успадкував конструктори присвоєння та копіювання за замовчуванням від C, і вони часто використовуються.

Тож замість "чому у C ++ немає за замовчуванням operator==()?", Питання повинне було бути "чому C ++ має конструктор присвоєння за замовчуванням та конструктор копій?", У відповіді на те, що ці елементи були включені неохоче Stroustrup для зворотної сумісності з C (можливо, причиною більшості бородавок C ++, але також, ймовірно, основною причиною популярності C ++).

Для моїх власних цілей у моєму IDE фрагмент, який я використовую для нових класів, містить декларації для приватного оператора присвоєння та конструктора копіювання, так що коли я створюю новий клас, я не отримую операцій з призначення та копіювання за замовчуванням - я повинен видалити декларацію тих операцій з private:розділу, якщо я хочу, щоб компілятор міг їх генерувати для мене.

Навіть у C ++ 20 компілятор все одно не буде неявно генерувати operator==для вас

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

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

Але ви отримаєте можливість явного дефолту == після 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;
};

Дефолт ==робить членом ==(так само, як конструктор копій за замовчуванням виконує конструювання копій для членів). Нові правила також передбачають очікувані відносини між ==та !=. Наприклад, за допомогою заяви вище, я можу написати і те, і інше:

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

Ця специфічна особливість (дефолт operator==та симетрія між ==та !=) походить від однієї пропозиції, яка була частиною більш широкої мовної функції operator<=>.

ІМХО, "доброї" причини немає. Причина, що так багато людей згодні з цим дизайнерським рішенням, полягає в тому, що вони не навчилися оволодіти силою ціннісної семантики. Людям потрібно писати багато спеціальних конструкторів копій, операторів порівняння та деструкторів, оскільки вони використовують необмежену вказівку для своєї реалізації.

При використанні відповідних інтелектуальних покажчиків (наприклад, std :: shared_ptr) конструктор копій за замовчуванням зазвичай прекрасний, і очевидна реалізація гіпотетичного оператора порівняння за замовчуванням була б такою ж чудовою.

На нього відповіли, що C ++ не зробив == тому, що C не зробив, і ось чому C забезпечує лише за замовчуванням =, але ні == на першому місці. C хотів зробити це просто: C реалізовано = memcpy; однак, == не може бути реалізований memcmp через прокладку. Оскільки прокладка не ініціалізована, memcmp говорить, що вони різні, хоча вони однакові. Така ж проблема існує і для порожнього класу: memcmp говорить, що вони різні, оскільки розмір порожніх класів не дорівнює нулю. Зверху видно, що реалізація == є складнішою, ніж реалізація = в C. Деякі приклади коду щодо цього. Ваша корекція оцінюється, якщо я помиляюся.

У цьому відео Олексій Степанов, автор STL, вирішує саме це питання близько 13:00. Підводячи підсумок, спостерігаючи за розвитком C ++, він стверджує, що:

• Прикро, що == і! = Неявно не оголошені (і Б'ярн погоджується з ним). Правильна мова повинна бути готова для вас (він продовжує підказувати, що ви не зможете визначити ! =, Що порушує семантику == )
• Причиною цього є коріння (стільки ж проблем C ++) у C. Там оператор присвоєння неявно визначений з бітовим призначенням, але це не працює для == . Більш детальне пояснення можна знайти в цій статті від Bjarne Stroustrup.
• У подальшому запитанні Чому тоді не був членом по використанню порівняння членів, він говорить дивовижну річ : C був якось домашньою мовою, і хлопець, що реалізував ці речі для Річі, сказав йому, що він вважає, що це важко реалізувати!

Потім він каже, що в (далекому) майбутньому = неявно буде генеруватися == і ! = .

C ++ 20 пропонує спосіб легко реалізувати оператор порівняння за замовчуванням.

Приклад із 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<=>

Неможливо визначити за замовчуванням ==, але ви можете визначити дефолт, за !=допомогою ==якого зазвичай слід визначити себе. Для цього слід зробити наступні дії:

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

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

Докладні відомості можна знайти на веб-сайті http://www.cplusplus.com/reference/std/utility/rel_ops/ .

Крім того, якщо ви визначите operator< , оператори для <=,>,> = можуть бути виведені з нього при використанні std::rel_ops.

Але ви повинні бути обережними при використанні, std::rel_opsоскільки оператори порівняння можуть бути виведені для типів, від яких ви не очікуєте.

Більш бажаний спосіб вивести пов'язаного оператора з базового - використовувати boost :: оператори .

Підхід, що використовується в boost, є кращим, оскільки він визначає використання оператора лише для класу, який ви хочете, а не для всіх класів за обсягом.

Ви також можете генерувати "+" з "+ =", - з "- =" тощо тощо (див. Повний список тут )

C ++ 0x має була пропозиція за замовчуванням функцій, так що ви могли б сказати , default operator==; ми дізналися , що це допомагає зробити ці речі явно.

Концептуально визначити рівність непросто. Навіть для даних POD можна стверджувати, що навіть якщо поля однакові, але це різний об'єкт (за різною адресою), він не обов'язково дорівнює. Це фактично залежить від використання оператора. На жаль, ваш компілятор не психічний і не може цього зробити.

Окрім цього, функції за замовчуванням - це відмінний спосіб стріляти в ногу. Описані за замовчуванням в основному існують для збереження сумісності зі структурами POD. Однак вони завдають більш ніж достатнього хаосу, коли розробники забувають про них, або семантику реалізацій за замовчуванням.

Чи є для цього вагома причина? Чому проведення порівняння по одному члену може бути проблемою?

Це може не бути проблемою функціонально, але з точки зору продуктивності порівняння за замовчуванням член-член може бути більш неоптимальним, ніж призначення / копіювання за замовчуванням член-член-член. На відміну від порядку призначення, порядок порівняння впливає на результативність, оскільки перший нерівний член передбачає, що решта може бути пропущена. Тож якщо є деякі члени, які зазвичай рівні, ви хочете порівняти їх останніми, і компілятор не знає, які члени, швидше за все, рівні.

Розглянемо цей приклад, де verboseDescriptionдовга струна обрана із відносно невеликого набору можливих погодних описів.

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
    }
}

(Звичайно, компілятор мав би право знехтувати порядком порівнянь, якщо визнає, що вони не мають побічних ефектів, але, мабуть, він все-таки відіб'є свою чергу з вихідного коду там, де не має кращої інформації.)

Просто так, що відповіді на це питання залишаються повними, як проходить час: оскільки C ++ 20 його можна автоматично генерувати за допомогою команди auto operator<=>(const foo&) const = default;

Він генерує всіх операторів: ==,! =, <, <=,> І> =, див. Https://en.cppreference.com/w/cpp/language/default_comparisons для детальної інформації.

Через зовнішній вигляд оператора <=>його називають оператором космічного корабля. Також дивіться, для чого нам потрібен оператор космічного корабля <=> в C ++? .

EDIT: Крім того, в C ++ 11 досить акуратний замінник , який доступний з std::tieсм https://en.cppreference.com/w/cpp/utility/tuple/tie для повного прикладу коду з bool operator<(…). Цікава частина, змінена для роботи з ==:

#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 працює з усіма операторами порівняння і повністю оптимізований компілятором.

Я згоден, для класів типу POD тоді компілятор міг би зробити це за вас. Однак те, що ви можете вважати простим, компілятор може помилитися. Тож краще дозволити програмісту це зробити.

Одного разу у мене був випадок POD, коли два поля були унікальними - тому порівняння ніколи не вважатиметься правдивим. Однак порівняння, яке мені потрібно було, коли-небудь порівнювало на корисну навантаження - те, що компілятор ніколи не зрозуміє і не міг зрозуміти, що це самостійно.

Крім того - писати їм не потрібно багато часу ?!