¿Por qué se prueba la desigualdad como (! (A == b)) en muchos códigos de biblioteca estándar de C ++?

Este es el código del código de la biblioteca estándar de C ++ remove. ¿Por qué se prueba la desigualdad en if (!(*first == val))lugar de 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;
 }

Porque esto significa que el único requisito en T es implementar un operator==. Podría requerir que T tenga una, operator!=pero la idea general aquí es que debe poner la menor carga posible en el usuario de la plantilla y otras plantillas sí lo necesitan operator==.

La mayoría de las funciones en STL solo funcionan con operator<o operator==. Esto requiere que el usuario solo implemente estos dos operadores (o, a veces, al menos uno de ellos). Por ejemplo, std::setutiliza operator<(más precisamente, std::lessqué invoca operator<por defecto) y no operator>para gestionar pedidos. La removeplantilla en su ejemplo es un caso similar: usa solo operator==y no operator!=así operator!=no necesita ser definido.

Este es el código de la biblioteca estándar de C ++ que elimina el código.

Incorrecto. No es elremove código de la biblioteca estándar de C ++ . Es una posible implementación interna de la removefunción de biblioteca estándar de C ++ . El estándar C ++ no prescribe el código real; Prescribe prototipos de funciones y comportamientos requeridos.

En otras palabras: desde un punto de vista estrictamente lingüístico, el código que está viendo no existe . Puede ser de algún archivo de encabezado que viene con la implementación de la biblioteca estándar de su compilador. Tenga en cuenta que el estándar C ++ ni siquiera requiere que existan esos archivos de encabezado . Los archivos son solo una forma conveniente para que los implementadores del compilador cumplan con los requisitos para una línea como #include <algorithm>(es decir, hacer std::removey otras funciones disponibles).

¿Por qué se prueba la desigualdad en if (!(*first == val))lugar de if (*first != val)?

Porque solo operator==es requerido por la función.

Cuando se trata de la sobrecarga del operador para tipos personalizados, el idioma le permite hacer todo tipo de cosas raras. Muy bien podría crear una clase que tenga una sobrecargada operator==pero no sobrecargada operator!=. O peor aún: podría sobrecargarse operator!=pero hacer que haga cosas completamente ajenas.

Considere este ejemplo:

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

Si se std::removeusa operator!=, el resultado sería bastante diferente.

Algunas buenas respuestas aquí. Solo quería agregar una pequeña nota.

Como todas las buenas bibliotecas, la biblioteca estándar está diseñada con (al menos) dos principios muy importantes en mente:

1. Ponga la menor cantidad de responsabilidad en los usuarios de su biblioteca con la que pueda salirse con la suya. Parte de esto tiene que ver con darles la menor cantidad de trabajo para hacer al usar su interfaz. (como definir la menor cantidad de operadores posible). La otra parte tiene que ver con no sorprenderlos o exigirles que verifiquen los códigos de error (así que mantenga las interfaces consistentes y arroje excepciones <stdexcept>cuando las cosas salgan mal).

2. Eliminar toda la redundancia lógica . Todas las comparaciones pueden deducirse simplemente de operator<, entonces, ¿por qué exigir que los usuarios definan a otros? p.ej:

   (a> b) es equivalente a (b <a)

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

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

   y así.

   Por supuesto, en esta nota, uno podría preguntarse por qué unordered_maprequiere operator==(al menos por defecto) en lugar de operator<. La respuesta es que en una tabla hash, la única comparación que necesitamos es una para la igualdad. Por lo tanto, es lógicamente más consistente (es decir, tiene más sentido para el usuario de la biblioteca) exigirles que definan un operador de igualdad. Requerir un operator<sería confuso porque no es inmediatamente obvio por qué lo necesitarías.

El EqualityComparableconcepto solo requiere que operator==se defina.

En consecuencia, cualquier función que profese trabajar con tipos satisfactorios EqualityComparable no puede depender de la existencia de operator!=objetos de ese tipo. (a menos que existan requisitos adicionales que impliquen la existencia de operator!=).

El enfoque más prometedor es encontrar un método para determinar si se puede llamar al operador == para un tipo particular, y luego apoyarlo solo cuando esté disponible; en otras situaciones, se lanzaría una excepción. Sin embargo, hasta la fecha no hay una forma conocida de detectar si una expresión de operador arbitraria f == g está adecuadamente definida. La mejor solución conocida tiene las siguientes cualidades indeseables:

• Falla en tiempo de compilación para objetos donde el operador == no es accesible (por ejemplo, porque es privado).
• Falla en tiempo de compilación si llamar al operador == es ambiguo.
• Parece correcto si la declaración de operador == es correcta, aunque el operador == no pueda compilar.

De Boost FAQ: fuente

Sabiendo que requerir una ==implementación es una carga , nunca querrás crear una carga adicional al requerir!= implementación también.

Para mí personalmente, se trata de la parte L SÓLIDA (diseño orientado a objetos): principio de sustitución de Liskov: "los objetos en un programa deben ser reemplazables con instancias de sus subtipos sin alterar la corrección de ese programa". En este caso, es el operador ! = Que puedo reemplazar con == y inversa booleana en lógica booleana.