Czy == i! = Są od siebie zależne?

Uczę się o przeciążenia operatora w C ++, i widzę, że ==i !=są po prostu pewne specjalne funkcje, które mogą być dostosowane do typów zdefiniowanych przez użytkownika. Martwię się jednak, dlaczego potrzebne są dwie osobne definicje? Myślałem, że jeśli a == bto prawda, a != bto automatycznie jest fałszem i odwrotnie, i nie ma innej możliwości, ponieważ z definicji tak a != bjest !(a == b). I nie wyobrażałem sobie żadnej sytuacji, w której to nie byłoby prawdą. Ale może moja wyobraźnia jest ograniczona, czy czegoś nie wiem?

Wiem, że mogę zdefiniować jedno w kategoriach drugiego, ale nie o to pytam. Nie pytam też o rozróżnienie między porównywaniem obiektów według wartości lub tożsamości. Lub czy dwa obiekty mogą być równe i nierównomierne jednocześnie (to zdecydowanie nie jest opcja! Te rzeczy wzajemnie się wykluczają). Pytam o to:

Czy jest jakakolwiek sytuacja, w której zadawanie pytań o równość dwóch przedmiotów ma sens, ale pytanie o nierówność między nimi nie ma sensu? (z perspektywy użytkownika lub z perspektywy implementatora)

Jeśli nie ma takiej możliwości, to dlaczego na Ziemi C ++ mają te dwa operatory zdefiniowane jako dwie odrębne funkcje?

Byś nie chcą językiem automatycznie przepisać a != bjako !(a == b)kiedy a == bpowróci coś innego niż bool. Istnieje kilka powodów, dla których możesz to zrobić.

Możesz mieć obiekty konstruktora wyrażeń, w których a == bnie ma i nie ma na celu przeprowadzania żadnego porównania, ale po prostu buduje jakiś reprezentujący węzeł wyrażenia a == b.

Możesz mieć leniwą ocenę, w której a == bnie ma i nie ma na celu bezpośredniego porównania, ale zamiast tego zwraca pewien rodzaj tego, lazy<bool>który można później przekształcić w boolsposób niejawny lub jawny, aby faktycznie wykonać porównanie. Prawdopodobnie w połączeniu z obiektami konstruktora wyrażeń, aby umożliwić pełną optymalizację wyrażeń przed oceną.

Możesz mieć niestandardową optional<T>klasę szablonów, w której podane są opcjonalne zmienne ti uchcesz zezwolić t == u, ale spraw , aby powróciła optional<bool>.

Jest chyba coś więcej, o czym nie myślałem. I chociaż w tych przykładach operacja a == bi a != boba mają sens, nadal a != bnie jest tym samym !(a == b), więc potrzebne są osobne definicje.

Jeśli nie ma takiej możliwości, to dlaczego na Ziemi C ++ mają te dwa operatory zdefiniowane jako dwie odrębne funkcje?

Ponieważ możesz je przeciążyć, a przeciążając je, możesz nadać im zupełnie inne znaczenie niż ich oryginalne.

Weźmy na przykład operator <<, pierwotnie bitowy operator przesunięcia w lewo, obecnie często przeciążony jako operator wstawiania, jak w std::cout << something; zupełnie inne znaczenie niż oryginalne.

Jeśli więc zaakceptujesz, że znaczenie operatora zmienia się, gdy go przeciążasz, nie ma powodu, aby uniemożliwić użytkownikowi nadanie operatorowi znaczenia, ==które nie jest dokładnie zaprzeczeniem operatora !=, choć może to być mylące.

Martwię się jednak, dlaczego potrzebne są dwie osobne definicje?

Nie musisz definiować obu.
Jeśli wzajemnie się wykluczają, nadal możesz być zwięzły, definiując tylko ==i <obok std :: rel_ops

Z preferencji:

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

Czy jest jakakolwiek sytuacja, w której zadawanie pytań o równość dwóch przedmiotów ma sens, ale pytanie o nierówność między nimi nie ma sensu?

Często kojarzymy tych operatorów z równością.
Chociaż tak zachowują się na podstawowych typach, nie ma obowiązku, aby takie było ich zachowanie na niestandardowych typach danych. Nie musisz nawet zwracać bool, jeśli nie chcesz.

Widziałem ludzi przeciążających operatorów w dziwny sposób, ale okazało się, że ma to sens w przypadku ich aplikacji. Nawet jeśli interfejs wydaje się wskazywać, że wzajemnie się wykluczają, autor może chcieć dodać określoną logikę wewnętrzną.

(z perspektywy użytkownika lub z perspektywy implementatora)

Wiem, że chcesz konkretnego przykładu,
więc oto jeden z frameworka Catch testing, który moim zdaniem był praktyczny:

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

Operatorzy ci robią różne rzeczy i nie ma sensu definiować jednej metody jako! (Nie) drugiej. Powodem tego jest to, że środowisko może wydrukować wykonane porównanie. W tym celu musi uchwycić kontekst użytego przeciążonego operatora.

Istnieje kilka bardzo dobrze ustalone konwencje, które (a == b)i (a != b)są zarówno fałszywe niekoniecznie przeciwieństwa. W szczególności w SQL każde porównanie z NULL daje NULL, nie jest prawdą ani fałszem.

Prawdopodobnie nie jest dobrym pomysłem tworzenie nowych przykładów, jeśli to w ogóle możliwe, ponieważ jest to tak mało intuicyjne, ale jeśli próbujesz modelować istniejącą konwencję, fajnie jest mieć opcję, aby Twoi operatorzy zachowywali się „poprawnie” w tym celu kontekst.

Odpowiem tylko na drugą część twojego pytania, a mianowicie:

Jeśli nie ma takiej możliwości, to dlaczego na Ziemi C ++ mają te dwa operatory zdefiniowane jako dwie odrębne funkcje?

Jednym z powodów, dla których warto pozwolić programistom na przeciążenie obu, jest wydajność. Możesz zezwolić na optymalizacje, wdrażając zarówno ==i !=. Wtedy x != ymoże być tańszy niż !(x == y)jest. Niektóre kompilatory mogą być w stanie zoptymalizować go dla Ciebie, ale być może nie, szczególnie jeśli masz złożone obiekty z dużą ilością rozgałęzień.

Nawet w Haskell, gdzie programiści bardzo poważnie podchodzą do praw i pojęć matematycznych, nadal można przeciążać oba == i/= , jak widać tutaj ( 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'

Prawdopodobnie byłoby to uważane za mikrooptymalizację, ale w niektórych przypadkach może być uzasadnione.

Czy jest jakakolwiek sytuacja, w której zadawanie pytań o równość dwóch przedmiotów ma sens, ale pytanie o nierówność między nimi nie ma sensu? (z perspektywy użytkownika lub z perspektywy implementatora)

To jest opinia. Może nie. Ale projektanci języka, nie będąc wszechwiedzący, postanowili nie ograniczać ludzi, którzy mogą wymyślić sytuacje, w których może to mieć sens (przynajmniej dla nich).

W odpowiedzi na edycję;

To znaczy, jeśli możliwe jest, aby jakiś typ miał operatora, ==ale nie !=odwrotnie, i kiedy ma to sens.

W ogóle , nie, to nie ma sensu. Operatory równości i relacji są zazwyczaj dostępne w zestawach. Jeśli jest równość, to również nierówność; mniej niż, to więcej niż i tak dalej z<= itd. Podobne podejście stosuje się również do operatorów arytmetycznych, one również ogólnie występują w naturalnych zestawach logicznych.

Dowodzi tego fakt std::rel_ops przestrzeń nazw. Jeśli zaimplementujesz równość i mniej niż operatorów, użycie tej przestrzeni nazw daje ci inne, zaimplementowane w kategoriach oryginalnych zaimplementowanych operatorów.

To powiedziawszy, czy istnieją warunki lub sytuacje, w których jedno nie oznaczałoby od razu drugiego lub nie można go wdrożyć w odniesieniu do innych? Tak, jest ich zapewne niewiele, ale oni tam są; ponownie, o czym świadczy rel_opsistnienie własnej przestrzeni nazw. Z tego powodu umożliwienie ich niezależnej implementacji umożliwia wykorzystanie języka w celu uzyskania potrzebnej lub potrzebnej semantyki w sposób, który jest nadal naturalny i intuicyjny dla użytkownika lub klienta kodu.

Wspomniana już leniwa ocena jest tego doskonałym przykładem. Innym dobrym przykładem jest nadanie im semantyki, która wcale nie oznacza równości lub nierówności. Podobnym przykładem są operatory przesunięcia bitów <<i >>stosowane do wstawiania i wydobywania strumienia. Chociaż może się to spotkać z niechęcią w kręgach ogólnych, w niektórych obszarach specyficznych dla domeny może mieć sens.

Jeśli ==i !=operatorzy nie faktycznie oznacza, równość, w taki sam sposób, że <<i>> operatorzy stream nie oznaczają przesunięcie bitów. Jeśli traktujesz te symbole tak, jakby oznaczały jakąś inną koncepcję, nie muszą się wzajemnie wykluczać.

Jeśli chodzi o równość, może mieć sens, jeśli twoja przypadek użycia uzasadnia traktowanie obiektów jako nieporównywalnych, aby każde porównanie zwróciło fałsz (lub nieporównywalny typ wyniku, jeśli operatorzy zwrócą wartość inną niż bool). Nie mogę wymyślić konkretnej sytuacji, w której byłoby to uzasadnione, ale widziałem, że jest to wystarczająco rozsądne.

Z wielką mocą przychodzi świetnie odpowiedzialny, a przynajmniej naprawdę dobry styl przewodników.

==i !=może być przeciążony, aby zrobić cokolwiek chcesz. To zarówno błogosławieństwo, jak i przekleństwo. Nie ma gwarancji, że !=to oznacza !(a==b).

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

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

Nie mogę uzasadnić przeciążenia tego operatora, ale w powyższym przykładzie nie można zdefiniować operator!=jako „przeciwieństwo” operator==.

W końcu sprawdzasz za pomocą tych operatorów, czy wyrażenie a == blub a != bzwraca wartość logiczną ( truelub false). Wyrażenie to zwraca wartość logiczną po porównaniu, a nie wyklucza się wzajemnie.

[..] dlaczego potrzebne są dwie oddzielne definicje?

Jedną rzeczą do rozważenia jest to, że może istnieć możliwość zaimplementowania jednego z tych operatorów bardziej efektywnie niż tylko zaprzeczenie drugiemu.

(Mój przykład tutaj to śmieci, ale kwestia nadal jest ważna, pomyśl o filtrach Bloom, na przykład: Pozwalają one na szybkie testowanie, jeśli czegoś nie ma w zestawie, ale sprawdzenie, czy jest w zestawie, może zająć dużo więcej czasu.)

[..] z definicji a != bjest !(a == b).

I to jako programista ponosisz odpowiedzialność. Prawdopodobnie dobrze jest napisać test.

Dostosowując zachowanie operatorów, możesz zmusić ich do robienia tego, co chcesz.

Możesz dostosować rzeczy. Na przykład możesz dostosować klasę. Obiekty tej klasy można porównać, po prostu sprawdzając określoną właściwość. Wiedząc, że tak jest, możesz napisać określony kod, który sprawdza tylko minimalne rzeczy, zamiast sprawdzać każdy bit każdej pojedynczej właściwości w całym obiekcie.

Wyobraź sobie przypadek, w którym możesz dowiedzieć się, że coś jest inne tak samo szybko, jeśli nie szybciej, niż możesz dowiedzieć się, że coś jest takie samo. To prawda, że ​​kiedy zorientujesz się, czy coś jest takie samo czy różne, możesz poznać coś przeciwnego, po prostu trochę odwracając. Jednak odwrócenie tego bitu jest dodatkową operacją. W niektórych przypadkach, gdy kod jest często ponownie uruchamiany, zapisanie jednej operacji (pomnożonej przez wiele razy) może spowodować ogólny wzrost prędkości. (Na przykład, jeśli zapisujesz jedną operację na piksel ekranu megapikselowego, to właśnie zapisałeś milion operacji. Pomnożony przez 60 ekranów na sekundę, a ty oszczędzasz jeszcze więcej operacji.)

Odpowiedź hvd zawiera dodatkowe przykłady.

Tak, ponieważ jeden oznacza „ekwiwalent”, a drugi oznacza „ekwiwalent”, a te warunki wzajemnie się wykluczają. Wszelkie inne znaczenie dla tego operatora jest mylące i należy go unikać wszelkimi środkami.

Może nieporównywalne reguła, gdzie a != bbył fałszywy i a == bbył fałszywy jak trochę bezpaństwowcem.

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