Dlaczego kompilatory C ++ nie definiują operatora == i operatora! =?

Jestem wielkim fanem pozwalania kompilatorowi na wykonanie dla ciebie jak największej pracy. Pisząc prostą klasę, kompilator może dać ci następujące za „za darmo”:

• Domyślny (pusty) konstruktor
• Konstruktor kopii
• Destruktor
• Operator przypisania ( operator=)

Ale wydaje się, że nie daje żadnych operatorów porównania - takich jak operator==lub operator!=. Na przykład:

class foo
{
public:
    std::string str_;
    int n_;
};

foo f1;        // Works
foo f2(f1);    // Works
foo f3;
f3 = f2;       // Works

if (f3 == f2)  // Fails
{ }

if (f3 != f2)  // Fails
{ }

Czy jest na to dobry powód? Dlaczego przeprowadzanie porównania poszczególnych członków byłoby problemem? Oczywiście, jeśli klasa przydzieli pamięć, to powinieneś być ostrożny, ale dla prostej klasy z pewnością kompilator mógłby to zrobić za Ciebie?

Kompilator nie będzie wiedział, czy chcesz porównanie wskaźnika czy głębokie (wewnętrzne) porównanie.

Bezpieczniej jest po prostu nie wdrożyć go i pozwolić programiście zrobić to sam. Następnie mogą dokonać wszystkich założeń, które im się podobają.

Argument, że jeśli kompilator może zapewnić domyślny konstruktor kopii, powinien być w stanie zapewnić podobny domyślny konstruktor operator==() ma pewien sens. Myślę, że powód podjęcia decyzji o niedostarczeniu generatora kompilatora dla tego operatora można odgadnąć na podstawie tego, co Stroustrup powiedział o domyślnym konstruktorze kopii w „The Design and Evolution of C ++” (Rozdział 11.4.1 - Kontrola kopiowania) :

Osobiście uważam za niefortunne, że operacje kopiowania są domyślnie zdefiniowane i zabraniam kopiowania obiektów wielu moich klas. Jednak C ++ odziedziczył domyślne C i konstruktory kopiowania po C i są one często używane.

Zamiast „dlaczego C ++ nie ma wartości domyślnej operator==() ?”, Pytanie powinno brzmieć „dlaczego C ++ ma domyślny konstruktor przypisania i kopiowania?”, Przy czym odpowiedź jest taka, że ​​Stroustrup niechętnie uwzględnił te elementy w celu zapewnienia wstecznej zgodności z C (prawdopodobnie przyczyną większości brodawek C ++, ale także prawdopodobnie główną przyczyną popularności C ++).

Na własne potrzeby w moim IDE fragment kodu, którego używam dla nowych klas, zawiera deklaracje dla prywatnego operatora przypisania i konstruktora kopiowania, więc gdy generuję nową klasę, nie otrzymuję żadnych domyślnych operacji przypisania i kopiowania - muszę jawnie usunąć deklarację tych operacji z private:sekcji, jeśli chcę, aby kompilator mógł je dla mnie wygenerować.

Nawet w C ++ 20 kompilator nadal nie będzie generował operator==dla ciebie domyślnie

struct foo
{
    std::string str;
    int n;
};

assert(foo{"Anton", 1} == foo{"Anton", 1}); // ill-formed

Ale zyskasz możliwość jawnego domyślnego działania == od C ++ 20 :

struct foo
{
    std::string str;
    int n;

    // either member form
    bool operator==(foo const&) const = default;
    // ... or friend form
    friend bool operator==(foo const&, foo const&) = default;
};

Domyślne ustawienie ==działa w zależności od członka ==(w taki sam sposób, jak domyślny konstruktor kopiuje w przypadku tworzenia kopii w zależności od członka). Nowe zasady zapewniają również oczekiwany związek między ==i !=. Na przykład dzięki powyższej deklaracji mogę napisać oba:

assert(foo{"Anton", 1} == foo{"Anton", 1}); // ok!
assert(foo{"Anton", 1} != foo{"Anton", 2}); // ok!

Ta szczególna funkcja (domyślna operator==i symetria pomiędzy ==i !=) pochodzi z jednej propozycji, która była częścią szerszej funkcji języka, którą jest operator<=>.

IMHO, nie ma „dobrego” powodu. Powodem, dla którego tak wielu ludzi zgadza się z tą decyzją projektową, jest to, że nie nauczyli się opanowywać potęgi semantyki opartej na wartościach. Ludzie muszą napisać wiele niestandardowych konstruktorów kopiowania, operatorów porównania i destruktorów, ponieważ używają surowych wskaźników w swojej implementacji.

Przy stosowaniu odpowiednich inteligentnych wskaźników (takich jak std :: shared_ptr) domyślny konstruktor kopii jest zwykle w porządku, a oczywista implementacja hipotetycznego domyślnego operatora porównania byłaby równie dobra.

Odpowiedź: C ++ nie zrobił ==, ponieważ C nie, a oto dlaczego C zapewnia tylko domyślną =, ale nie == na pierwszym miejscu. C chciał uprościć: C zaimplementowane = przez memcpy; jednak == nie może zostać zaimplementowane przez memcmp z powodu wypełniania. Ponieważ padding nie jest inicjowany, memcmp mówi, że są różne, mimo że są takie same. Ten sam problem istnieje w przypadku pustych klas: memcmp mówi, że są one różne, ponieważ wielkość pustych klas nie jest równa zero. Z góry widać, że implementacja == jest bardziej skomplikowana niż implementacja = w C. Niektóre przykłady kodu dotyczące tego. Twoja poprawka jest mile widziana, jeśli się mylę.

W tym filmie Alex Stepanov, twórca STL, odpowiada na to pytanie około godziny 13:00. Podsumowując, obserwując ewolucję C ++, twierdzi, że:

• Szkoda, że == i! = Nie są niejawnie zadeklarowane (a Bjarne się z nim zgadza). Właściwy język powinien mieć te rzeczy gotowe (dalej sugeruje, że nie powinieneś być w stanie zdefiniować ! = , Który łamie semantykę == )
• Przyczyna tego przypadku ma swoje korzenie (jak wiele problemów w C ++) w C. Tam operator przypisania jest domyślnie definiowany za pomocą przypisania krok po kroku, ale to nie działałoby dla == . Bardziej szczegółowe wyjaśnienie można znaleźć w tym artykule Bjarne Stroustrup.
• W kolejnym pytaniu, dlaczego nie wykorzystano członka porównania członków , mówi niesamowitą rzecz : C był rodzimym językiem, a facet wdrażający te rzeczy dla Ritchie powiedział mu, że jest to trudne do wdrożenia!

Następnie mówi, że w (odległej) przyszłości == i ! = Zostaną domyślnie wygenerowane.

C ++ 20 zapewnia sposób na łatwą implementację domyślnego operatora porównania.

Przykład z cppreference.com :

class Point {
    int x;
    int y;
public:
    auto operator<=>(const Point&) const = default;
    // ... non-comparison functions ...
};

// compiler implicitly declares operator== and all four relational operators work
Point pt1, pt2;
if (pt1 == pt2) { /*...*/ } // ok, calls implicit Point::operator==
std::set<Point> s; // ok
s.insert(pt1); // ok
if (pt1 <= pt2) { /*...*/ } // ok, makes only a single call to Point::operator<=>

Nie można zdefiniować wartości domyślnej ==, ale można zdefiniować wartość domyślną, !=za pomocą ==której zwykle należy się zdefiniować. W tym celu należy wykonać następujące czynności:

#include <utility>
using namespace std::rel_ops;
...

class FooClass
{
public:
  bool operator== (const FooClass& other) const {
  // ...
  }
};

Szczegółowe informacje można znaleźć na stronie http://www.cplusplus.com/reference/std/utility/rel_ops/ .

Ponadto, jeśli zdefiniujesz operator< , operatory dla <=,>,> = można z niego wywnioskować podczas używania std::rel_ops.

Należy jednak zachować ostrożność podczas korzystania, std::rel_opsponieważ operatory porównania można wywnioskować dla typów, których się nie oczekuje.

Bardziej preferowanym sposobem na wyciągnięcie powiązanego operatora z podstawowego jest użycie boost :: operators .

Podejście zastosowane w boost jest lepsze, ponieważ definiuje użycie operatora dla klasy, którą chcesz, a nie dla wszystkich klas w zakresie.

Możesz również wygenerować „+” z „+ =”, - z „- =” itd. (Zobacz pełną listę tutaj )

C ++ 0x ma propozycję domyślnych funkcji, więc można powiedzieć, default operator==; że dowiedzieliśmy się, że pomaga to wyjaśnić te rzeczy.

Koncepcyjnie nie jest łatwo zdefiniować równość. Nawet w przypadku danych POD można argumentować, że nawet jeśli pola są takie same, ale jest to inny obiekt (pod innym adresem), niekoniecznie jest on równy. To zależy od sposobu użytkowania operatora. Niestety twój kompilator nie jest medium i nie może tego wywnioskować.

Poza tym domyślne funkcje to doskonały sposób na zastrzelenie się w stopę. Opisane wartości domyślne mają zasadniczo na celu zachowanie zgodności ze strukturami POD. Powodują one jednak więcej niż wystarczające spustoszenie, gdy programiści zapominają o nich lub semantykę domyślnych implementacji.

Czy jest na to dobry powód? Dlaczego przeprowadzanie porównania poszczególnych członków byłoby problemem?

Może to nie być problem funkcjonalnie, ale pod względem wydajności domyślne porównanie poszczególnych członków może być bardziej nieoptymalne niż domyślne przypisanie / kopiowanie poszczególnych członków. W przeciwieństwie do kolejności przypisywania, kolejność porównywania wpływa na wydajność, ponieważ pierwszy nierówny element oznacza, że ​​resztę można pominąć. Więc jeśli istnieją elementy, które są zwykle równe, chcesz je porównać na końcu, a kompilator nie wie, które elementy są bardziej prawdopodobne.

Rozważ ten przykład, gdzie verboseDescriptionjest długi ciąg wybrany ze stosunkowo niewielkiego zestawu możliwych opisów pogody.

class LocalWeatherRecord {
    std::string verboseDescription;
    std::tm date;
    bool operator==(const LocalWeatherRecord& other){
        return date==other.date
            && verboseDescription==other.verboseDescription;
    // The above makes a lot more sense than
     // return verboseDescription==other.verboseDescription
     //     && date==other.date;
    // because some verboseDescriptions are liable to be same/similar
    }
}

(Oczywiście kompilator byłby uprawniony do zignorowania kolejności porównań, gdyby rozpoznał, że nie mają one żadnych skutków ubocznych, ale przypuszczalnie nadal pobierałby swoją kolejkę od kodu źródłowego, w którym nie ma lepszych informacji).

Wystarczy, że odpowiedzi na to pytanie pozostaną kompletne w miarę upływu czasu: od C ++ 20 można go automatycznie wygenerować za pomocą polecenia auto operator<=>(const foo&) const = default;

Wygeneruje wszystkie operatory: ==,! =, <, <=,> I> =, patrz https://en.cppreference.com/w/cpp/language/default_comparisons celu uzyskania szczegółowych informacji.

Ze względu na wygląd operatora <=>nazywany jest operatorem statku kosmicznego. Zobacz także Dlaczego potrzebujemy operatora statku kosmicznego <=> w C ++?.

EDIT: również w C ++ 11 całkiem schludny substytutem, który jest dostępny z std::tiezobaczyć https://en.cppreference.com/w/cpp/utility/tuple/tie dla kompletnego przykład kodu z bool operator<(…). Interesującą częścią, zmienioną do pracy, ==jest:

#include <tuple>

struct S {
………
bool operator==(const S& rhs) const
    {
        // compares n to rhs.n,
        // then s to rhs.s,
        // then d to rhs.d
        return std::tie(n, s, d) == std::tie(rhs.n, rhs.s, rhs.d);
    }
};

std::tie działa ze wszystkimi operatorami porównania i jest całkowicie zoptymalizowany przez kompilator.

Zgadzam się, w przypadku klas typu POD kompilator mógłby zrobić to za Ciebie. Jednak to, co możesz uznać za proste, kompilator może się nie powieść. Lepiej więc pozwolić programiście to zrobić.

Miałem kiedyś przypadek POD, w którym dwa pola były unikalne - więc porównanie nigdy nie będzie uważane za prawdziwe. Jednak porównanie, którego potrzebowałem, porównywałem tylko ładunek - coś, czego kompilator nigdy nie zrozumie lub nigdy nie będzie w stanie samodzielnie zrozumieć.

Poza tym - nie trzeba długo pisać, prawda ?!