Dlaczego nierówność jest testowana jako (! (A == b)) w wielu standardowych kodach bibliotek C ++?

To jest kod ze standardowego removekodu biblioteki C ++ . Dlaczego nierówność jest testowana jako if (!(*first == val))zamiast 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;
 }

Ponieważ oznacza to, że jedynym wymaganiem na T jest implementacja operator==. Możesz wymagać od T, aby mieć, operator!=ale ogólna idea jest taka, że ​​powinieneś obciążać użytkownika szablonu jak najmniejszym, a inne szablony wymagają operator==.

Większość funkcji w STL działa tylko z operator<lub operator==. Wymaga to od użytkownika tylko zaimplementowania tych dwóch operatorów (lub czasami przynajmniej jednego z nich). Na przykład std::setużywa operator<(a dokładniej, std::lessktóra wywołuje operator<domyślnie), a nie operator>do zarządzania kolejnością. removeSzablon w przykładzie jest podobny przypadek - używa tylko operator==i nie operator!=tak operator!=nie musi być zdefiniowana.

To jest kod z kodu usuwania biblioteki standardowej C ++.

Źle. To nie jest standardowy removekod biblioteki C ++ . Jest to jedna z możliwych implementacji wewnętrznej biblioteki standardowej C ++remove funkcji . Standard C ++ nie określa faktycznego kodu; zawiera prototypy funkcji i wymagane zachowania.

Innymi słowy: ze ścisłego punktu widzenia języka kod, który widzisz , nie istnieje . Może pochodzić z jakiegoś pliku nagłówkowego, który jest dostarczany z implementacją biblioteki standardów kompilatora. Zauważ, że standard C ++ nie wymaga nawet istnienia tych plików nagłówkowych . Pliki są po prostu wygodnym sposobem dla implementujących kompilatory, aby spełnić wymagania dla linii #include <algorithm>(tj. std::removeUdostępnianie i inne funkcje).

Dlaczego nierówność jest testowana jako if (!(*first == val))zamiast if (*first != val)?

Ponieważ operator==wymaga tego tylko funkcja.

Jeśli chodzi o przeciążanie operatorów dla typów niestandardowych, język pozwala robić różne dziwne rzeczy. Możesz bardzo dobrze stworzyć klasę, która ma przeciążoną, operator==ale nie przeciążoną operator!=. Lub nawet gorzej: możesz przeciążaćoperator!= ale sprawić, by robił zupełnie niezwiązane rzeczy.

Rozważmy ten przykład:

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

Jeśli zostanie std::removeużyty operator!=, wynik byłby zupełnie inny.

Kilka dobrych odpowiedzi. Chciałem tylko dodać małą notatkę.

Podobnie jak wszystkie dobre biblioteki, biblioteka standardowa została zaprojektowana z uwzględnieniem (co najmniej) dwóch bardzo ważnych zasad:

1. Połóż najmniejszą odpowiedzialność na użytkownikach swojej biblioteki, z którą możesz uciec. Częściowo wiąże się to z poświęceniem im najmniejszej ilości pracy podczas korzystania z interfejsu. (np. zdefiniowanie jak najmniejszej liczby operatorów). Druga część polega na tym, że nie zaskakuje ich ani nie wymaga od nich sprawdzania kodów błędów (więc zachowaj spójność interfejsów i zgłaszaj wyjątki, <stdexcept>gdy coś pójdzie nie tak).

2. Wyeliminuj całą logiczną nadmiarowość . Wszystkie porównania można wyprowadzić po prostu zoperator< , więc po co żądać, aby użytkownicy definiowali innych? na przykład:

   (a> b) jest równoważne (b <a)

   (a> = b) jest równoważne! (a <b)

   (a == b) jest równoważne! ((a <b) || (b <a))

   i tak dalej.

   Oczywiście w tej notatce można zapytać, dlaczego unordered_mapwymaga operator==(przynajmniej domyślnie), a nie operator<. Odpowiedź jest taka, że ​​w tabeli skrótów jedyne porównanie, jakiego kiedykolwiek potrzebujemy, dotyczy równości. Dlatego jest bardziej logicznie spójne (tj. Ma większy sens dla użytkownika biblioteki), aby wymagać od niego zdefiniowania operatora równości. Wymaganie operator<byłoby mylące, ponieważ nie jest od razu oczywiste, dlaczego go potrzebujesz.

EqualityComparablePojęcie tylko wymaga,operator== być zdefiniowane.

W konsekwencji żadna funkcja, która twierdzi, że działa z typami spełniającymi, EqualityComparable nie może polegać na istnieniu operator!=obiektów for tego typu. (chyba że istnieją dodatkowe wymagania, które implikują istnienie operator!=).

Najbardziej obiecującym podejściem jest znalezienie metody określania, czy operator == można wywołać dla określonego typu, a następnie wspieranie go tylko wtedy, gdy jest dostępny; w innych sytuacjach zostałby zgłoszony wyjątek. Jednak do tej pory nie jest znany sposób wykrycia, czy dowolne wyrażenie operatora f == g jest odpowiednio zdefiniowane. Najlepsze znane rozwiązanie ma następujące niepożądane cechy:

• Niepowodzenie w czasie kompilacji dla obiektów, w których operator == nie jest dostępny (np. Ponieważ jest prywatny).
• Niepowodzenie w czasie kompilacji, jeśli operator wywołujący == jest niejednoznaczny.
• Wydaje się poprawne, jeśli deklaracja operatora == jest poprawna, nawet jeśli operator == może się nie kompilować.

Od Często zadawane pytania dotyczące Boost: źródło

Wiedząc, że wymaganie ==implementacji jest obciążeniem , nigdy nie chcesz stwarzać dodatkowego obciążenia wymaganiem!= implementacji.

Dla mnie osobiście chodzi o SOLID (projektowanie obiektowe) L część - zasada podstawienia Liskova: „obiekty w programie powinny być zastępowalne instancjami ich podtypów bez zmiany poprawności tego programu”. W tym przypadku jest to operator ! = , Który mogę zastąpić znakiem == i odwrotnością boolowską w logice boolowskiej.