Perché la disuguaglianza è testata come (! (A == b)) in molti codici di libreria standard C ++?

Questo è il codice dal codice della libreria standard C ++ remove. Perché la disuguaglianza è testata come if (!(*first == val))anziché 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;
 }

Perché questo significa che l'unico requisito su T è implementare un operator==. Potresti richiedere a T di avere un'idea, operator!=ma l'idea generale qui è che dovresti mettere il minor onere possibile sull'utilizzatore del modello e che altri modelli hanno bisogno operator==.

La maggior parte delle funzioni in STL funziona solo con operator<o operator==. Ciò richiede all'utente di implementare solo questi due operatori (o talvolta almeno uno di essi). Ad esempio std::setutilizza operator<(più precisamente std::lessche invoca operator<per impostazione predefinita) e non operator>gestire l'ordinamento. Il removemodello nel tuo esempio è un caso simile: utilizza solo operator==e non è operator!=quindi operator!=necessario definire.

Questo è il codice del codice di rimozione della libreria standard C ++.

Sbagliato. Non è ilremove codice della libreria standard C ++ . È una possibile implementazione interna della removefunzione di libreria standard C ++ . Lo standard C ++ non prescrive il codice effettivo; prescrive prototipi funzionali e comportamenti richiesti.

In altre parole: da un punto di vista linguistico rigoroso, il codice che vedi non esiste . Potrebbe provenire da un file di intestazione fornito con l'implementazione della libreria standard del compilatore. Si noti che lo standard C ++ non richiede nemmeno l' esistenza di quei file di intestazione . I file sono solo un modo conveniente per gli implementatori di compilatori di soddisfare i requisiti di una linea simile #include <algorithm>(ovvero rendere disponibili std::removee altre funzioni).

Perché la disuguaglianza è testata come if (!(*first == val))anziché if (*first != val)?

Perché operator==è richiesto solo dalla funzione.

Quando si tratta di sovraccarico dell'operatore per tipi personalizzati, la lingua ti consente di fare tutti i tipi di cose strane. Si potrebbe benissimo creare una classe che ha un sovraccarico operator==ma non sovraccarico operator!=. O peggio ancora: potresti sovraccaricarti operator!=ma fare cose completamente indipendenti.

Considera questo esempio:

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

Se std::removeutilizzato operator!=, il risultato sarebbe piuttosto diverso.

Alcune buone risposte qui. Volevo solo aggiungere una piccola nota.

Come tutte le buone librerie, la libreria standard è progettata con (almeno) due principi molto importanti in mente:

1. Metti la minima quantità di responsabilità sugli utenti della tua biblioteca con cui puoi cavartela. Parte di questo ha a che fare con il dare loro il minor numero di lavoro da fare quando si utilizza l'interfaccia. (come definire il minor numero di operatori con cui puoi cavartela). L'altra parte ha a che fare con non sorprenderli o richiedere loro di controllare i codici di errore (quindi mantenere coerenti le interfacce e gettare eccezioni da <stdexcept>quando le cose vanno male).

2. Elimina tutta la ridondanza logica . Tutti i confronti possono essere dedotti semplicemente da operator<, quindi perché chiedere agli utenti di definirne altri? per esempio:

   (a> b) è equivalente a (b <a)

   (a> = b) è equivalente a! (a <b)

   (a == b) è equivalente a! ((a <b) || (b <a))

   e così via.

   Naturalmente su questa nota, ci si potrebbe chiedere perché unordered_maprichiede operator==(almeno per impostazione predefinita) piuttosto che operator<. La risposta è che in una tabella hash l'unico confronto che abbiamo mai richiesto è uno per l'uguaglianza. Quindi è logicamente più coerente (cioè ha più senso per l'utente della biblioteca) richiedere loro di definire un operatore di uguaglianza. Richiedere un operator<sarebbe confuso perché non è immediatamente ovvio il motivo per cui ne avresti bisogno.

Il EqualityComparableconcetto richiede solo questooperator== sia definito.

Di conseguenza, qualsiasi funzione che professa di lavorare con tipi soddisfacenti EqualityComparable non può fare affidamento sull'esistenza di operator!=oggetti di quel tipo. (a meno che non vi siano requisiti aggiuntivi che implicano l'esistenza di operator!=).

L'approccio più promettente è trovare un metodo per determinare se l'operatore == può essere chiamato per un tipo particolare e quindi supportarlo solo quando è disponibile; in altre situazioni, verrebbe generata un'eccezione. Tuttavia, ad oggi non è noto alcun modo per rilevare se un'espressione di operatore arbitrario f == g è adeguatamente definita. La migliore soluzione conosciuta ha le seguenti qualità indesiderabili:

• Errore in fase di compilazione per oggetti in cui operator == non è accessibile (ad es. Perché è privato).
• Errore durante la compilazione se chiamare l'operatore == è ambiguo.
• Sembra essere corretto se l'operatore == la dichiarazione è corretta, anche se l'operatore == potrebbe non essere compilato.

Da Boost FAQ: fonte

Sapendo che richiedere l' ==implementazione è un onere , non si vuole mai creare un onere aggiuntivo richiedendo!= implementazione.

Per me personalmente si tratta di SOLID (design orientato agli oggetti) Parte L - Principio di sostituzione di Liskov: "gli oggetti in un programma dovrebbero essere sostituibili con istanze dei loro sottotipi senza alterare la correttezza di quel programma.". In questo caso è l'operatore ! = Che posso sostituire con == e l'inverso booleano nella logica booleana.