== e! = Sono reciprocamente dipendenti?

Sto imparando circa l'overloading degli operatori in C ++, e vedo che ==e !=sono semplicemente alcune funzioni speciali che possono essere personalizzati per i tipi definiti dall'utente. La mia preoccupazione è, tuttavia, perché sono necessarie due definizioni separate ? Ho pensato che se a == bè vero, allora a != bè automaticamente falso, e viceversa, e non c'è altra possibilità, perché, per definizione, lo a != bè !(a == b). E non riuscivo a immaginare alcuna situazione in cui ciò non fosse vero. Ma forse la mia immaginazione è limitata o ignoro qualcosa?

So di poter definire l'uno in termini di altro, ma non è questo ciò di cui mi sto chiedendo. Inoltre, non sto chiedendo la distinzione tra confrontare oggetti per valore o per identità. O se due oggetti potrebbero essere uguali e non uguali allo stesso tempo (questa non è sicuramente un'opzione! Queste cose si escludono a vicenda). Quello che sto chiedendo è questo:

C'è qualche situazione possibile in cui ha senso porre domande su due oggetti uguali, ma non ha senso chiederle se non sono uguali? (dal punto di vista dell'utente o dal punto di vista dell'implementatore)

Se non esiste tale possibilità, perché sulla Terra il C ++ ha questi due operatori definiti come due funzioni distinte?

Si potrebbe non voler la lingua per riscrivere automaticamente a != bcome !(a == b)quando a == britorna qualcosa di diverso da un bool. E ci sono alcuni motivi per cui potresti farlo farlo.

Potresti avere oggetti del generatore di espressioni, dove a == bno e non è destinato a eseguire alcun confronto, ma crea semplicemente un nodo di espressione che rappresenta a == b.

Potresti avere una valutazione pigra, dove a == bno e non è prevista l'esecuzione diretta di alcun confronto, ma restituisce invece un tipo di lazy<bool>ciò che può essere convertito in modo boolimplicito o esplicito in un momento successivo per eseguire effettivamente il confronto. Eventualmente combinato con gli oggetti del generatore di espressioni per consentire l'ottimizzazione completa delle espressioni prima della valutazione.

Potresti avere una optional<T>classe di template personalizzata , dove sono fornite variabili opzionali te u, vuoi permetterlo t == u, ma fallo tornare optional<bool>.

Probabilmente c'è altro a cui non ho pensato. E anche se in questi esempi l'operazione a == be a != bentrambe hanno un senso, a != bnon è ancora la stessa cosa !(a == b), quindi sono necessarie definizioni separate.

Se non esiste tale possibilità, perché sulla Terra il C ++ ha questi due operatori definiti come due funzioni distinte?

Perché puoi sovraccaricarli e sovraccaricandoli puoi dare loro un significato totalmente diverso da quello originale.

Prendiamo, ad esempio, l'operatore <<, originariamente l'operatore di spostamento a sinistra bit a bit, ora comunemente sovraccaricato come operatore di inserimento, come in std::cout << something; significato totalmente diverso da quello originale.

Pertanto, se si accetta che il significato di un operatore cambia quando lo si sovraccarica, non vi è motivo di impedire all'utente di dare un significato all'operatore ==che non sia esattamente la negazione dell'operatore !=, sebbene ciò possa creare confusione.

La mia preoccupazione è, tuttavia, perché sono necessarie due definizioni separate?

Non è necessario definire entrambi.
Se si escludono a vicenda, puoi comunque essere conciso solo definendo ==e <affiancando std :: rel_ops

Per riferimento:

#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';
}

C'è qualche situazione possibile in cui ha senso porre domande su due oggetti uguali, ma non ha senso chiederle se non sono uguali?

Associamo spesso questi operatori all'uguaglianza.
Sebbene sia così che si comportano su tipi fondamentali, non vi è alcun obbligo che questo sia il loro comportamento su tipi di dati personalizzati. Non devi nemmeno restituire un bool se non vuoi.

Ho visto persone sovraccaricare gli operatori in modi bizzarri, solo per scoprire che ha senso per la loro specifica applicazione di dominio. Anche se l'interfaccia sembra mostrare che si escludono a vicenda, l'autore potrebbe voler aggiungere una logica interna specifica.

(dal punto di vista dell'utente o dal punto di vista dell'implementatore)

So che vuoi un esempio specifico,
quindi eccone uno dal framework di test Catch che pensavo fosse pratico:

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 );
}

Questi operatori stanno facendo cose diverse e non avrebbe senso definire un metodo come! (Non) dell'altro. Il motivo è che il framework può stampare il confronto effettuato. Per fare ciò, deve catturare il contesto dell'operatore sovraccarico utilizzato.

Ci sono alcune convenzioni ben consolidate in cui (a == b)e (a != b)sono entrambi falsi, non necessariamente opposti. In particolare, in SQL, qualsiasi confronto con NULL produce NULL, non vero o falso.

Probabilmente non è una buona idea creare nuovi esempi di questo, se possibile, perché è così poco intuitivo, ma se stai cercando di modellare una convenzione esistente, è bello avere l'opzione per far sì che i tuoi operatori si comportino "correttamente" per quello contesto.

Risponderò solo alla seconda parte della tua domanda, vale a dire:

Se non esiste tale possibilità, perché sulla Terra il C ++ ha questi due operatori definiti come due funzioni distinte?

Uno dei motivi per cui ha senso consentire allo sviluppatore di sovraccaricare entrambi è la prestazione. È possibile consentire le ottimizzazioni implementando sia ==e !=. Quindi x != ypotrebbe essere più economico di!(x == y) è. Alcuni compilatori potrebbero essere in grado di ottimizzarlo per te, ma forse no, soprattutto se hai oggetti complessi con molte ramificazioni.

Anche a Haskell, dove gli sviluppatori prendono molto sul serio leggi e concetti matematici, si può ancora sovraccaricare entrambi ==e /=, come potete vedere qui ( 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'

Questo sarebbe probabilmente considerato micro-ottimizzazione, ma potrebbe essere giustificato per alcuni casi.

C'è qualche situazione possibile in cui ha senso porre domande su due oggetti uguali, ma non ha senso chiederle se non sono uguali? (dal punto di vista dell'utente o dal punto di vista dell'implementatore)

Questa è un'opinione. Forse no. Ma i progettisti del linguaggio, non essendo onniscienti, hanno deciso di non limitare le persone che potrebbero inventare situazioni in cui potrebbe avere senso (almeno per loro).

In risposta alla modifica;

Cioè, se è possibile per un tipo avere l'operatore ==ma non il !=, o viceversa, e quando ha senso farlo.

In generale , no, non ha senso. L'uguaglianza e gli operatori relazionali generalmente si presentano in serie. Se esiste l'uguaglianza, anche la disuguaglianza; meno di, quindi maggiore di e così via con il<= ecc. Un approccio simile viene applicato anche agli operatori aritmetici, che generalmente vengono anche in set logici naturali.

Ciò è evidenziato nel std::rel_ops spazio nomi. Se si implementa l'uguaglianza e meno degli operatori, l'utilizzo di quello spazio dei nomi ti dà gli altri, implementati in termini di operatori implementati originali.

Detto questo, ci sono condizioni o situazioni in cui l'una non significherebbe immediatamente l'altra o non potrebbe essere implementata in termini di altre? Sì, ce ne sono , probabilmente pochi, ma ci sono; di nuovo, come evidenziato nelrel_ops dall'essere uno spazio dei nomi a sé stante. Per questo motivo, consentire loro di essere implementati in modo indipendente consente di sfruttare la lingua per ottenere la semantica richiesta o necessaria in un modo ancora naturale e intuitivo per l'utente o il cliente del codice.

La valutazione pigra già menzionata ne è un eccellente esempio. Un altro buon esempio è dare loro la semantica che non significa affatto uguaglianza o disuguaglianza. Un esempio simile a questo sono gli operatori bit shift <<e >>utilizzati per l'inserimento e l'estrazione del flusso. Sebbene possa essere disapprovato nei circoli generali, in alcune aree specifiche del dominio può avere un senso.

Se gli operatori ==e !=non implicano effettivamente l'uguaglianza, allo stesso modo in cui gli operatori <<e >>stream non implicano lo spostamento dei bit. Se tratti i simboli come se significassero qualche altro concetto, non devono escludersi a vicenda.

In termini di uguaglianza, potrebbe avere senso se il tuo caso d'uso garantisca il trattamento di oggetti come non comparabili, in modo che ogni confronto dovrebbe restituire falso (o un tipo di risultato non confrontabile, se i tuoi operatori restituiscono non-bool). Non riesco a pensare a una situazione specifica in cui ciò sarebbe giustificato, ma ho potuto vederlo abbastanza ragionevole.

Con una grande potenza arriva una grande responsabilità, o almeno delle ottime guide di stile.

==e !=può essere sovraccarico per fare qualunque diavolo tu voglia. È sia una benedizione che una maledizione. Non c'è garanzia che !=significhi !(a==b).

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

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

Non posso giustificare questo sovraccarico dell'operatore, ma nell'esempio sopra è impossibile definire operator!="l'opposto" di operator==.

Alla fine, ciò che si sta verificando con quegli operatori è che l'espressione a == bo a != bsta restituendo un valore booleano ( trueo false). Questa espressione restituisce un valore booleano dopo il confronto anziché essere reciprocamente esclusive.

[..] perché sono necessarie due definizioni separate?

Una cosa da considerare è che potrebbe esserci la possibilità di implementare uno di questi operatori in modo più efficiente rispetto al semplice utilizzo della negazione dell'altro.

(Il mio esempio qui è stato spazzatura, ma il punto è ancora valido, pensate ai filtri di fioritura, ad esempio: consentono test rapidi se qualcosa non è in un set, ma testare se è in può richiedere molto più tempo.)

[..] per definizione, a != bè !(a == b).

Ed è tua responsabilità come programmatore mantenere questa presa. Probabilmente una buona cosa per cui scrivere un test.

Personalizzando il comportamento degli operatori, puoi farli fare quello che vuoi.

Potresti voler personalizzare le cose. Ad esempio, potresti voler personalizzare una classe. Gli oggetti di questa classe possono essere confrontati semplicemente controllando una proprietà specifica. Sapendo che questo è il caso, puoi scrivere un codice specifico che controlla solo le cose minime, invece di controllare ogni singolo bit di ogni singola proprietà nell'intero oggetto.

Immagina un caso in cui puoi capire che qualcosa è diverso altrettanto velocemente, se non più velocemente, di quanto puoi scoprire che qualcosa è lo stesso. Certo, una volta capito se qualcosa è uguale o diverso, allora puoi conoscere il contrario semplicemente girando un po '. Tuttavia, capovolgere quel bit è un'operazione extra. In alcuni casi, quando il codice viene rieseguito molto, il salvataggio di un'operazione (moltiplicato per molte volte) può comportare un aumento complessivo della velocità. (Ad esempio, se si salva un'operazione per pixel di uno schermo megapixel, allora si è appena salvato un milione di operazioni. Moltiplicato per 60 schermi al secondo e si risparmiano ancora più operazioni.)

la risposta di hvd fornisce alcuni esempi aggiuntivi.

Sì, perché uno significa "equivalente" e un altro significa "non equivalente" e questi termini si escludono a vicenda. Qualsiasi altro significato per questo operatore è confuso e dovrebbe essere evitato con ogni mezzo.

Forse una regola incomparabile, dove a != bera falso ed a == bera falso come un bit apolide.

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