Geschichte der Frage
Vor C++20 implementierten Entwickler manuell sechs Vergleichsoperatoren für sortierbare Typen. Dieser Boilerplate-Code führte häufig zu subtilen logischen Inkonsistenzen zwischen Gleichheits- und Ordnungsverhältnissen. Der Raumschiffoperator wurde eingeführt, um diese in eine einzige kanonische Operation zu konsolidieren.
Das Problem
Während operator<=> die Syntax reduziert, verlässt sich der Compiler auf seinen Rückgabewert, um umgekehrte Ausdrücke wie b < a aus a > b zu synthetisieren. Ohne zu wissen, ob die Ordnung streng, schwach oder teilweise ist, kann der Compiler diese Umformungen nicht sicher erzeugen.
Die Lösung
Der Rückgabewert muss std::strong_ordering, std::weak_ordering oder std::partial_ordering (oder implizit konvertierbar) sein. Diese Standardkategorie ermöglicht es dem Compiler, umgekehrte Kandidaten und implizite Gleichheitsprüfungen zu generieren. Das Zurückgeben von auto oder benutzerdefinierten Typen deaktiviert diese Synthese und erfordert manuelle asymmetrische Überladungen.
struct Widget { int id; // Korrekt: ermöglicht die Generierung umgekehrter Kandidaten std::strong_ordering operator<=>(const Widget&) const = default; };
Szenario und Problem
Die Entwicklung eines SpatialIndex für GPU-beschleunigte Geometrien erforderte eine BoundingBox-Struktur mit strenger schwacher Ordnung für die Einfügung in std::set. Die Boxen mussten mit rohen Koordinatenarrays für räumliche Abfragen vergleichen.
Lösung 1: Manuelle Operatorüberladung
Die Implementierung von zwölf Überladungen (sechs für BoundingBox, sechs für Koordinatenarrays) bot explizite Kontrolle. Die Ausführlichkeit riskierte jedoch Copy-Paste-Fehler zwischen operator< und operator>, und die Aufrechterhaltung der Konsistenz während Refactorings erwies sich als mühsam.
Lösung 2: Vorgenerierter Raumschiffoperator, der std::weak_ordering zurückgibt
Dies generierte automatisch alle relationalen Operatoren aus einer einzigen Deklaration. Der explizite Rückgabewert erlaubte es dem Compiler, umgekehrte Vergleiche mit Koordinatenarrays zu handhaben. Die Implementierung garantierte Ausnahme-Sicherheit und mathematische Konsistenz ohne Boilerplate.
Lösung 3: Auto-Rückgabe
Die Verwendung von auto operator<=>(const BoundingBox&) const = default verhinderte die Synthese umgekehrter Kandidaten. Der Vergleich eines rohen Arrays links mit einer BoundingBox rechts konnte nicht kompiliert werden. Diese Asymmetrie brach die Schnittstelle der räumlichen Abfrage.
Entscheidung und Ergebnis
Wir wählten Lösung 2 mit std::weak_ordering, da Bounding-Boxen Gleichheit (überlappende Boxen vergleichen gleich) aber keine mathematische Gleichheit haben. Dies ermöglichte eine nahtlose Integration mit Standardalgorithmen, während heterogene Koordinatenvergleiche unterstützt wurden.
Warum synthetisiert der Compiler operator== aus operator<=> und wann ist das suboptimal?
Der Compiler generiert operator== als ((*this <=> other) == 0). Dies sorgt für Konsistenz, zwingt jedoch zu einem vollständigen elementweisen Vergleich, selbst wenn nur Gleichheit überprüft wird. Das explizite Standardisieren von operator== ermöglicht eine Kurzschlussauswertung, die false sofort beim ersten unterschiedlichen Mitglied zurückgibt.
Wie bricht die Definition von operator<=> als Mitglied anstelle eines versteckten Freundes die Symmetrie?
Ein Mitglied operator<=> erlaubt nur implizite Konversionen beim rechten Operanden während der Überladungsauflösung. Diese Asymmetrie verhindert, dass Ausdrücke wie double == MyClass kompiliert werden, selbst wenn MyClass aus double konstruiert werden kann. Die Verwendung eines versteckten Freundes ermöglicht die Argumentabhängige Suche (ADL), so dass beide Operanden implizit konvertiert werden können.
Was unterscheidet std::compare_three_way von manuellen Zeigervergleichen?
std::compare_three_way bietet eine totale Ordnung für Zeiger, die im gesamten Adressraum konsistent ist, einschließlich std::nullptr_t. Manuelle Zeigervergleiche mithilfe relationaler Operatoren rufen undefiniertes Verhalten hervor, wenn nicht verwandte Objekte verglichen werden. Die Verwendung des Standardfunktionsobjekts gewährleistet tragbare, gut definierte Semantiken für die Zeigersortierung.