Warum definieren C ++ - Compiler nicht operator == und operator! =?

Ich bin ein großer Fan davon, den Compiler so viel Arbeit wie möglich für Sie erledigen zu lassen. Beim Schreiben einer einfachen Klasse kann der Compiler Ihnen Folgendes kostenlos zur Verfügung stellen:

• Ein Standardkonstruktor (leer)
• Ein Kopierkonstruktor
• Ein Zerstörer
• Ein Zuweisungsoperator ( operator=)

Es kann Ihnen jedoch keine Vergleichsoperatoren geben - wie operator==oder operator!=. Zum Beispiel:

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
{ }

Gibt es dafür einen guten Grund? Warum sollte ein Vergleich von Mitglied zu Mitglied ein Problem sein? Wenn die Klasse Speicher zuweist, möchten Sie natürlich vorsichtig sein, aber für eine einfache Klasse könnte der Compiler dies sicherlich für Sie tun?

Der Compiler würde nicht wissen, ob Sie einen Zeigervergleich oder einen tiefen (internen) Vergleich wünschen.

Es ist sicherer, es einfach nicht zu implementieren und den Programmierer das selbst tun zu lassen. Dann können sie alle Annahmen treffen, die sie mögen.

Das Argument, dass der Compiler, wenn er einen Standardkopierkonstruktor bereitstellen kann, einen ähnlichen Standard bereitstellen kann, operator==()ist in gewissem Maße sinnvoll. Ich denke, dass der Grund für die Entscheidung, keinen vom Compiler generierten Standard für diesen Operator bereitzustellen, durch die Aussagen von Stroustrup zum Standardkopierkonstruktor in "Das Design und die Entwicklung von C ++" (Abschnitt 11.4.1 - Kontrolle des Kopierens) erraten werden kann. ::

Ich persönlich halte es für bedauerlich, dass Kopiervorgänge standardmäßig definiert sind, und ich verbiete das Kopieren von Objekten vieler meiner Klassen. C ++ hat jedoch seine Standardzuweisungs- und Kopierkonstruktoren von C geerbt und sie werden häufig verwendet.

Anstelle von "Warum hat C ++ keine Standardeinstellung operator==()?" Sollte die Frage lauten: "Warum hat C ++ eine Standardzuweisung und einen Kopierkonstruktor?". Die Antwort lautete, dass diese Elemente von Stroustrup aus Gründen der Abwärtskompatibilität mit C nur ungern aufgenommen wurden (wahrscheinlich die Ursache für die meisten Warzen von C ++, aber wahrscheinlich auch der Hauptgrund für die Popularität von C ++).

Für meine eigenen Zwecke enthält das Snippet, das ich für neue Klassen verwende, in meiner IDE Deklarationen für einen privaten Zuweisungsoperator und einen Kopierkonstruktor, sodass ich beim Erstellen einer neuen Klasse keine Standardzuweisungen und Kopiervorgänge erhalte. Ich muss die Deklaration explizit entfernen dieser Operationen aus dem private:Abschnitt, wenn ich möchte, dass der Compiler sie für mich generieren kann.

Selbst in C ++ 20 generiert der Compiler nicht implizit operator==für Sie

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

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

Seit C ++ 20 können Sie jedoch explizit Standardwerte == festlegen :

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

Die Standardeinstellung ==erfolgt in Bezug auf die Mitglieder ==(auf die gleiche Weise wie der Standardkopierkonstruktor in Bezug auf die Mitglieder ). Die neuen Regeln bieten auch die erwartete Beziehung zwischen ==und !=. Zum Beispiel kann ich mit der obigen Erklärung beides schreiben:

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

Diese spezielle Funktion (Standardeinstellung operator==und Symmetrie zwischen ==und !=) stammt aus einem Vorschlag , der Teil der umfassenderen Sprachfunktion war operator<=>.

IMHO gibt es keinen "guten" Grund. Der Grund, warum es so viele Menschen gibt, die dieser Entwurfsentscheidung zustimmen, ist, dass sie nicht gelernt haben, die Kraft der wertebasierten Semantik zu beherrschen. Die Benutzer müssen viele benutzerdefinierte Kopierkonstruktoren, Vergleichsoperatoren und Destruktoren schreiben, da sie in ihrer Implementierung Rohzeiger verwenden.

Bei Verwendung geeigneter intelligenter Zeiger (wie std :: shared_ptr) ist der Standardkopierkonstruktor normalerweise in Ordnung, und die offensichtliche Implementierung des hypothetischen Standardvergleichsoperators wäre ebenso in Ordnung.

Es wurde geantwortet, dass C ++ nicht == getan hat, weil C nicht getan hat, und hier ist, warum C nur Standard = aber kein == an erster Stelle bereitstellt. C wollte es einfach halten: C implementiert = von memcpy; == kann jedoch aufgrund des Auffüllens nicht von memcmp implementiert werden. Da das Auffüllen nicht initialisiert wird, gibt memcmp an, dass sie unterschiedlich sind, obwohl sie gleich sind. Das gleiche Problem besteht für leere Klassen: memcmp gibt an, dass sie unterschiedlich sind, da die Größe leerer Klassen nicht Null ist. Es kann von oben zu sehen, dass die Umsetzung == ist komplizierter als = in C einige Code Implementierung Beispiel in Bezug auf diese. Ihre Korrektur wird geschätzt, wenn ich falsch liege.

In diesem Video spricht Alex Stepanov, der Schöpfer von STL, genau diese Frage gegen 13:00 Uhr an. Zusammenfassend argumentiert er, nachdem er die Entwicklung von C ++ beobachtet hat, dass:

• Es ist bedauerlich, dass == und! = Nicht implizit deklariert werden (und Bjarne stimmt ihm zu). Eine korrekte Sprache sollte diese Dinge für Sie bereithalten (er schlägt weiter vor, dass Sie nicht in der Lage sein sollten, ein ! = Zu definieren , das die Semantik von == bricht ).
• Der Grund, warum dies der Fall ist, hat seine Wurzeln (wie viele C ++ - Probleme) in C. Dort wird der Zuweisungsoperator implizit mit einer bitweisen Zuweisung definiert, aber das würde für == nicht funktionieren . Eine ausführlichere Erklärung finden Sie in diesem Artikel von Bjarne Stroustrup.
• In der Folgefrage, warum dann kein Mitglied im Vergleich verwendet wurde , sagt er etwas Erstaunliches : C war eine Art einheimische Sprache, und der Typ, der diese Dinge für Ritchie implementierte, sagte ihm, er finde es schwierig, dies zu implementieren!

Er sagt dann, dass in (ferner) Zukunft == und ! = Implizit generiert werden.

C ++ 20 bietet eine Möglichkeit, einen Standardvergleichsoperator einfach zu implementieren.

Beispiel von 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<=>

Es ist nicht möglich, Standard zu definieren ==, aber Sie können Standard definieren, !=über ==den Sie sich normalerweise selbst definieren sollten. Dazu sollten Sie folgende Dinge tun:

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

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

Weitere Informationen finden Sie unter http://www.cplusplus.com/reference/std/utility/rel_ops/ .

Wenn Sie definieren operator< , können außerdem Operatoren für <=,>,> = bei der Verwendung daraus abgeleitet werden std::rel_ops.

Bei der Verwendung sollten Sie jedoch vorsichtig sein, std::rel_opsda Vergleichsoperatoren für die Typen abgeleitet werden können, für die Sie nicht erwartet werden.

Die bevorzugte Methode, um verwandte Operatoren von einfachen abzuleiten, ist die Verwendung von boost :: -Operatoren .

Der in Boost verwendete Ansatz ist besser, da er die Verwendung des Operators für die Klasse definiert, die Sie nur möchten, nicht für alle Klassen im Gültigkeitsbereich.

Sie können auch "+" aus "+ =", - aus "- =" usw. generieren (siehe vollständige Liste hier )

C ++ 0x hat einen Vorschlag für Standardfunktionen. Man könnte also sagen, default operator==; wir haben gelernt, dass es hilfreich ist, diese Dinge explizit zu machen.

Konzeptionell ist es nicht einfach, Gleichheit zu definieren. Selbst für POD-Daten könnte man argumentieren, dass selbst wenn die Felder gleich sind, es sich jedoch um ein anderes Objekt (an einer anderen Adresse) handelt, es nicht unbedingt gleich ist. Dies hängt tatsächlich von der Verwendung des Bedieners ab. Leider ist Ihr Compiler nicht psychisch und kann daraus nicht schließen.

Außerdem sind Standardfunktionen hervorragende Möglichkeiten, sich in den Fuß zu schießen. Die von Ihnen beschriebenen Standardeinstellungen dienen im Wesentlichen der Kompatibilität mit POD-Strukturen. Sie verursachen jedoch mehr als genug Chaos, wenn Entwickler sie oder die Semantik der Standardimplementierungen vergessen.

Gibt es dafür einen guten Grund? Warum sollte ein Vergleich von Mitglied zu Mitglied ein Problem sein?

Funktionell ist dies möglicherweise kein Problem, aber in Bezug auf die Leistung ist der Standardvergleich von Mitglied zu Mitglied möglicherweise nicht optimaler als die Standardzuweisung / das Kopieren von Mitglied zu Mitglied. Im Gegensatz zur Reihenfolge der Zuweisung wirkt sich die Reihenfolge des Vergleichs auf die Leistung aus, da das erste ungleiche Mitglied impliziert, dass der Rest übersprungen werden kann. Wenn es also einige Mitglieder gibt, die normalerweise gleich sind, möchten Sie sie zuletzt vergleichen, und der Compiler weiß nicht, welche Mitglieder mit größerer Wahrscheinlichkeit gleich sind.

Betrachten Sie dieses Beispiel, in dem verboseDescriptioneine lange Zeichenfolge aus einem relativ kleinen Satz möglicher Wetterbeschreibungen ausgewählt wird.

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

(Natürlich wäre der Compiler berechtigt, die Reihenfolge der Vergleiche zu ignorieren, wenn er erkennt, dass sie keine Nebenwirkungen haben, aber vermutlich würde er seine Warteschlange immer noch aus dem Quellcode entnehmen, wo er selbst keine besseren Informationen hat.)

Nur damit die Antworten auf diese Frage im Laufe der Zeit vollständig bleiben: Seit C ++ 20 kann sie automatisch mit Befehl generiert werden auto operator<=>(const foo&) const = default;

Es werden alle Operatoren generiert: == ,! =, <, <=,> Und> =, Einzelheiten finden Sie unter https://en.cppreference.com/w/cpp/language/default_comparisons .

Aufgrund des Aussehens des Bedieners <=>wird es als Raumschiffbetreiber bezeichnet. Siehe auch Warum benötigen wir den Raumschiffoperator <=> in C ++? .

BEARBEITEN: Auch in C ++ 11 ist ein ziemlich guter Ersatz dafür verfügbar. Ein vollständiges Codebeispiel mit finden std::tieSie unter https://en.cppreference.com/w/cpp/utility/tuple/tiebool operator<(…) . Der interessante Teil, mit dem gearbeitet wurde, ==ist:

#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 funktioniert mit allen Vergleichsoperatoren und wird vom Compiler vollständig optimiert.

Ich stimme zu, für POD-Typklassen könnte der Compiler dies für Sie tun. Was Sie jedoch für einfach halten, kann der Compiler falsch machen. Es ist also besser, den Programmierer das tun zu lassen.

Ich hatte einmal einen POD-Fall, in dem zwei der Felder eindeutig waren - ein Vergleich würde also niemals als wahr angesehen werden. Der Vergleich, den ich brauchte, wurde jedoch immer nur mit der Nutzlast verglichen - etwas, das der Compiler niemals verstehen würde oder jemals selbst herausfinden könnte.

Außerdem - das Schreiben dauert nicht lange, oder?!