== e! = São mutuamente dependentes?

Estou aprendendo sobre a sobrecarga de operadores em C ++ e vejo isso ==e !=são simplesmente algumas funções especiais que podem ser personalizadas para tipos definidos pelo usuário. Minha preocupação é, porém, por que são necessárias duas definições separadas ? Eu pensei que se a == bé verdade, então a != bé automaticamente falsa e vice-versa, e não há outra possibilidade, porque, por definição, a != bé !(a == b). E eu não conseguia imaginar nenhuma situação em que isso não fosse verdade. Mas talvez minha imaginação seja limitada ou eu ignore alguma coisa?

Eu sei que posso definir um em termos do outro, mas não é sobre isso que estou perguntando. Também não estou perguntando sobre a distinção entre comparar objetos por valor ou por identidade. Ou se dois objetos podem ser iguais e não iguais ao mesmo tempo (isso definitivamente não é uma opção! Essas coisas são mutuamente exclusivas). O que estou perguntando é o seguinte:

Existe alguma situação possível em que fazer perguntas sobre dois objetos serem iguais faz sentido, mas perguntar sobre eles não serem iguais não faz sentido? (da perspectiva do usuário ou da perspectiva do implementador)

Se não existe essa possibilidade, por que C ++ na Terra esses dois operadores são definidos como duas funções distintas?

Você poderia não deseja que o idioma para reescrever automaticamente a != bcomo !(a == b)quando a == bretorna algo diferente de um bool. E há algumas razões pelas quais você pode fazer isso.

Você pode ter objetos do construtor de expressões, nos quais a == bnão tem e não se destina a realizar nenhuma comparação, mas simplesmente cria algum nó de expressão representando a == b.

Você pode ter uma avaliação preguiçosa, onde a == bnão pretende e não realiza nenhuma comparação diretamente, mas retorna algum tipo lazy<bool>que pode ser convertido em boolimplicitamente ou explicitamente em algum momento posterior para realmente executar a comparação. Possivelmente combinado com os objetos do construtor de expressões para permitir otimização completa da expressão antes da avaliação.

Você pode ter alguma optional<T>classe de modelo personalizada , onde são fornecidas variáveis ​​opcionais te u, você deseja permitir t == u, mas faça com que ela retorne optional<bool>.

Provavelmente há mais em que não pensei. E mesmo que nesses exemplos a operação a == be a != bas duas façam sentido, ainda a != bnão é a mesma coisa !(a == b), portanto são necessárias definições separadas.

Se não existe essa possibilidade, por que C ++ na Terra esses dois operadores são definidos como duas funções distintas?

Porque você pode sobrecarregá-los e, sobrecarregando-os, pode dar a eles um significado totalmente diferente do original.

Tomemos, por exemplo, operador <<, originalmente o operador de mudança à esquerda bit a bit, agora geralmente sobrecarregado como um operador de inserção, como em std::cout << something; significado totalmente diferente do original.

Portanto, se você aceitar que o significado de um operador muda quando você o sobrecarrega, não há motivo para impedir que o usuário dê um significado ao operador ==que não seja exatamente a negação do operador !=, embora isso possa ser confuso.

Minha preocupação é, porém, por que são necessárias duas definições separadas?

Você não precisa definir os dois.
Se eles são mutuamente exclusivos, você ainda pode ser conciso definindo apenas ==e <ao lado de std :: rel_ops

De preferência:

#include <iostream>
#include <utility>

struct Foo {
    int n;
};

bool operator==(const Foo& lhs, const Foo& rhs)
{
    return lhs.n == rhs.n;
}

bool operator<(const Foo& lhs, const Foo& rhs)
{
    return lhs.n < rhs.n;
}

int main()
{
    Foo f1 = {1};
    Foo f2 = {2};
    using namespace std::rel_ops;

    //all work as you would expect
    std::cout << "not equal:     : " << (f1 != f2) << '\n';
    std::cout << "greater:       : " << (f1 > f2) << '\n';
    std::cout << "less equal:    : " << (f1 <= f2) << '\n';
    std::cout << "greater equal: : " << (f1 >= f2) << '\n';
}

Existe alguma situação possível em que fazer perguntas sobre dois objetos serem iguais faz sentido, mas perguntar sobre eles não serem iguais não faz sentido?

Frequentemente, associamos esses operadores à igualdade.
Embora seja assim que eles se comportam em tipos fundamentais, não há obrigação de que esse seja o comportamento deles em tipos de dados personalizados. Você nem precisa retornar um bool se não quiser.

Vi pessoas sobrecarregar os operadores de maneiras bizarras, apenas para descobrir que faz sentido para a aplicação específica de seu domínio. Mesmo que a interface pareça mostrar que eles são mutuamente exclusivos, o autor pode querer adicionar lógica interna específica.

(da perspectiva do usuário ou da perspectiva do implementador)

Eu sei que você quer um exemplo específico,
então aqui está um da estrutura de teste Catch que eu pensei que era prático:

template<typename RhsT>
ResultBuilder& operator == ( RhsT const& rhs ) {
    return captureExpression<Internal::IsEqualTo>( rhs );
}

template<typename RhsT>
ResultBuilder& operator != ( RhsT const& rhs ) {
    return captureExpression<Internal::IsNotEqualTo>( rhs );
}

Esses operadores estão fazendo coisas diferentes, e não faria sentido definir um método como um! (Não) do outro. A razão disso é que o framework pode imprimir a comparação feita. Para fazer isso, ele precisa capturar o contexto de qual operador sobrecarregado foi usado.

Existem algumas convenções muito bem estabelecidas nas quais (a == b)e ambos(a != b) são falsos, não necessariamente opostos. Em particular, no SQL, qualquer comparação com NULL produz NULL, não é verdadeiro ou falso.

Provavelmente, não é uma boa ideia criar novos exemplos disso, se possível, porque é tão pouco intuitivo, mas se você estiver tentando modelar uma convenção existente, é bom ter a opção de fazer com que seus operadores se comportem "corretamente" para isso. contexto.

Eu responderei apenas a segunda parte da sua pergunta, a saber:

Se não existe essa possibilidade, por que C ++ na Terra esses dois operadores são definidos como duas funções distintas?

Uma razão pela qual faz sentido permitir que o desenvolvedor sobrecarregue ambos é o desempenho. Você pode permitir otimizações implementando ambos ==e !=. Então x != ypode ser mais barato do que !(x == y)é. Alguns compiladores podem otimizar para você, mas talvez não, especialmente se você tiver objetos complexos com muitas ramificações envolvidas.

Mesmo em Haskell, onde os desenvolvedores levam leis e conceitos matemáticos muito a sério, ainda é permitido sobrecarregar ambos ==e /=, como você pode ver aqui ( http://hackage.haskell.org/package/base-4.9.0.0/docs/Prelude .html # v: -61--61- ):

$ ghci
GHCi, version 7.10.2: http://www.haskell.org/ghc/  :? for help
λ> :i Eq
class Eq a where
  (==) :: a -> a -> Bool
  (/=) :: a -> a -> Bool
        -- Defined in `GHC.Classes'

Isso provavelmente seria considerado micro-otimização, mas pode ser justificado em alguns casos.

Existe alguma situação possível em que fazer perguntas sobre dois objetos serem iguais faz sentido, mas perguntar sobre eles não serem iguais não faz sentido? (da perspectiva do usuário ou da perspectiva do implementador)

Essa é uma opinião. Talvez não. Mas os designers de linguagem, por não serem oniscientes, decidiram não restringir as pessoas que poderiam ter situações em que isso pudesse fazer sentido (pelo menos para elas).

Em resposta à edição;

Ou seja, se é possível que algum tipo tenha o operador, ==mas não o !=, ou vice-versa, e quando faz sentido fazê-lo.

Em geral , não, não faz sentido. Operadores relacionais e de igualdade geralmente vêm em conjuntos. Se existe a igualdade, também a desigualdade; menos que, então maior que e assim por diante com o <=etc. Uma abordagem semelhante também é aplicada aos operadores aritméticos, eles geralmente também vêm em conjuntos lógicos naturais.

Isso é evidenciado no std::rel_opsespaço para nome. Se você implementar a igualdade e menos que operadores, o uso desse espaço para nome fornecerá os outros, implementados em termos de seus operadores implementados originais.

Dito isto, existem condições ou situações em que um não significaria imediatamente o outro ou não poderia ser implementado em termos dos outros? Sim, existem , sem dúvida, poucos, mas eles estão lá; novamente, como evidenciado por rel_opsser um espaço de nome próprio. Por esse motivo, permitir que eles sejam implementados de forma independente permite que você aproveite o idioma para obter a semântica necessária ou requerida de uma maneira ainda natural e intuitiva para o usuário ou cliente do código.

A avaliação preguiçosa já mencionada é um excelente exemplo disso. Outro bom exemplo é dar a eles semânticas que não significam igualdade ou desigualdade. Um exemplo semelhante a este são os operadores de troca de bits <<e >>sendo usados ​​para inserção e extração de fluxo. Embora possa ser desaprovado nos círculos gerais, em algumas áreas específicas do domínio, pode fazer sentido.

Se os operadores ==e !=realmente não implicam igualdade, da mesma forma que os operadores <<e >>stream não implicam mudança de bits. Se você tratar os símbolos como se eles significassem algum outro conceito, eles não precisam ser mutuamente exclusivos.

Em termos de igualdade, faria sentido se o seu caso de uso justificasse o tratamento de objetos como não comparáveis, para que toda comparação retorne falso (ou um tipo de resultado não comparável, se seus operadores retornarem não booleanos). Não consigo pensar em uma situação específica em que isso seria justificado, mas pude ver que isso é razoável o suficiente.

Com grande poder, é ótimo responsável, ou pelo menos realmente bons guias de estilo.

==e !=pode ser sobrecarregado para fazer o que você quiser. É uma bênção e uma maldição. Não há garantia de que isso !=signifique !(a==b).

enum BoolPlus {
    kFalse = 0,
    kTrue = 1,
    kFileNotFound = -1
}

BoolPlus operator==(File& other);
BoolPlus operator!=(File& other);

Não posso justificar essa sobrecarga de operador, mas no exemplo acima é impossível definir operator!=como o "oposto" de operator==.

No final, o que você está verificando com esses operadores é que a expressão a == bou a != bestá retornando um valor booleano ( trueou false). Essa expressão retorna um valor booleano após a comparação, em vez de ser mutuamente exclusiva.

[..] por que são necessárias duas definições separadas?

Uma coisa a considerar é que pode haver a possibilidade de implementar um desses operadores com mais eficiência do que apenas usar a negação do outro.

(Meu exemplo aqui foi lixo, mas o ponto ainda permanece, pense nos filtros de bloom, por exemplo: Eles permitem testes rápidos se algo não estiver em um conjunto, mas testar se estiver dentro pode levar muito mais tempo.)

[..] por definição, a != bé !(a == b).

E é sua responsabilidade como programador fazer isso. Provavelmente é uma boa coisa para se escrever um teste.

Ao personalizar o comportamento dos operadores, você pode fazê-los fazer o que quiser.

Você pode personalizar as coisas. Por exemplo, você pode personalizar uma classe. Objetos desta classe podem ser comparados apenas verificando uma propriedade específica. Sabendo que esse é o caso, você pode escrever um código específico que apenas verifique as coisas mínimas, em vez de verificar cada bit de cada propriedade no objeto inteiro.

Imagine um caso em que você possa descobrir que algo é diferente com a mesma rapidez, se não mais rápido, do que descobrir que algo é o mesmo. É verdade que, depois de descobrir se algo é igual ou diferente, você pode saber o contrário simplesmente mudando um pouco. No entanto, inverter esse bit é uma operação extra. Em alguns casos, quando o código é reexecutado muito, salvar uma operação (multiplicada por várias vezes) pode ter um aumento geral na velocidade. (Por exemplo, se você salvar uma operação por pixel de uma tela de megapixel, poderá salvar um milhão de operações. Multiplicado por 60 telas por segundo e salvar ainda mais operações.)

A resposta do hvd fornece alguns exemplos adicionais.

Sim, porque um significa "equivalente" e outro significa "não equivalente" e esses termos são mutuamente exclusivos. Qualquer outro significado para esses operadores é confuso e deve ser evitado por todos os meios.

Talvez uma regra incomparável, onde a != bera falsa e a == bera falsa como um pouco apátrida.

if( !(a == b || a != b) ){
    // Stateless
}