Почему неравенство проверяется как (! (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. Лучшее из известных решений имеет следующие нежелательные качества:

• Сбой во время компиляции для объектов, где operator == недоступен (например, потому что он закрытый).
• Сбой во время компиляции, если вызов оператора == является неоднозначным.
• Представляется правильным, если объявление оператора == правильное, даже если оператор == может не скомпилироваться.

Из Boost FAQ: источник

Зная, что требовать ==внедрения - это бремя , вы никогда не захотите создавать дополнительное бремя, требуя также и !=реализации.

Лично для меня это L-часть SOLID (объектно-ориентированное проектирование) - принцип подстановки Лискова: «объекты в программе должны заменяться экземплярами их подтипов без изменения правильности этой программы». В этом случае это оператор ! = , Который я могу заменить на == и логическое обратное в логической логике.