Чому нерівність перевіряється як (! (A == b)) у великій кількості стандартного коду бібліотеки C ++?

Це код із стандартного removeкоду бібліотеки C ++ . Чому нерівність перевіряється як if (!(*first == val))замість 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;
 }

Тому що це означає, що єдиною вимогою на T є реалізація operator==. Ви можете зажадати від T, operator!=але тут загальна ідея полягає в тому, що ви повинні накласти якомога менше навантаження на користувача шаблону та інших шаблонів operator==.

Більшість функцій STL працюють лише з operator<або operator==. Це вимагає від користувача лише впровадження цих двох операторів (або іноді хоча б одного з них). Наприклад, std::setвикористовує operator<(точніше, std::lessякий викликає operator<за замовчуванням), а не operator>керувати замовленнями. removeШаблон у вашому прикладі подібний випадок - він використовує тільки operator==і не operator!=так operator!=не повинні бути визначені.

Це код із коду видалення зі стандартної бібліотеки C ++.

Неправильно. Це не C ++ стандартної бібліотеки коду. Це одна можлива внутрішня реалізація стандартної функції бібліотеки C ++ . Стандарт C ++ не прописує фактичний код; Це передбачає функціонування прототипів і вимагає поведінки.removeremove

Іншими словами: З суворої мовної точки зору код, який ви бачите , не існує . Це може бути з якогось файла заголовка, який постачається зі стандартною реалізацією бібліотеки вашого компілятора. Зауважте, що стандарт C ++ навіть не вимагає наявності цих заголовкових файлів . Файли - це просто зручний спосіб, щоб виконавці-компілятори відповідали вимогам для такої лінії #include <algorithm>(тобто надання std::removeта доступність інших функцій).

Чому нерівність перевіряється як if (!(*first == val))замість if (*first != val)?

Тому що operator==вимагає лише функція.

Якщо мова йде про перевантаження оператора для користувацьких типів, мова дозволяє робити всі види дивних речей. Ви могли б дуже добре створити клас, який перевантажений, operator==але не перевантажений operator!=. Або ще гірше: ви можете перевантажувати, operator!=але змушувати це робити абсолютно не пов'язані між собою речі.

Розглянемо цей приклад:

#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());
  // ...
}

Якщо std::removeвикористовувати operator!=, то результат був би зовсім іншим.

Тут є кілька хороших відповідей. Я просто хотів додати невеличку замітку.

Як і всі хороші бібліотеки, стандартна бібліотека розроблена з (принаймні) двома дуже важливими принципами:

1. Покладіть найменшу відповідальність на користувачів вашої бібліотеки, від яких ви можете піти. Частина цього пов'язана з тим, щоб приділити їм найменший обсяг роботи при використанні вашого інтерфейсу. (наприклад, визначити якомога менше операторів). Інша частина цього стосується того, щоб не дивувати їх чи вимагати від них перевірки кодів помилок (тому дотримуйтесь послідовності інтерфейсів та кидайте винятки, <stdexcept>коли справи йдуть не так).

2. Усуньте всі логічні надмірності . Усі порівняння можна вивести лише з того operator<, чому ж вимагати, щоб користувачі визначали інших? наприклад:

   (a> b) еквівалентно (b <a)

   (a> = b) еквівалентно! (a <b)

   (a == b) еквівалентно! ((a <b) || (b <a))

   і так далі.

   Звичайно, у цій примітці можна запитати, чому unordered_mapпотрібно operator==(принаймні за замовчуванням), а не operator<. Відповідь полягає в тому, що в хеш-таблиці єдине порівняння, яке ми потребуємо, - це рівність. Таким чином, більш логічно послідовно (тобто має більше сенсу користувач бібліотеки) вимагати від них визначення оператора рівності. Потрібна запит operator<буде заплутаною, оскільки не відразу зрозуміло, для чого вона вам потрібна.

EqualityComparableПоняття тільки вимагає , щоб operator==визначити.

Отже, будь-яка функція, яка спричиняє роботу з типами, що задовольняють, EqualityComparable не може покладатися на існування operator!=для об'єктів цього типу. (якщо немає додаткових вимог, які передбачають існування operator!=).

Найбільш перспективним підходом є пошук способу визначення, чи може оператор == викликати певний тип, а потім підтримувати його лише тоді, коли він доступний; в інших ситуаціях буде викинуто виняток. Однак на сьогоднішній день не існує відомого способу виявити, чи довільно визначений довільний вираз оператора f == g. Найкраще відоме рішення має такі небажані якості:

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

З Boost FAQ: джерело

Знаючи, що вимагати ==впровадження є тягарем , ви ніколи не хочете створювати додатковий тягар, вимагаючи також !=реалізації.

Для мене особисто йдеться про SOLID (об'єктно-орієнтований дизайн) L частина - принцип заміни Ліскова: "Об'єкти в програмі повинні бути замінними екземплярами їх підтипів, не змінюючи правильність цієї програми". У цьому випадку оператор ! = Що я можу замінити на == та булеву зворотну в логічній логіці.