Probleme mit std::sort, std::ranges::sort und eigenem < Operator

[*john 0]

@Anon-81275 sagte in Probleme mit std::sort, std::ranges::sort und eigenem < Operator:

Warum scheitert die manuelle Version?

Wenn du den operator<=> von Hand schreibst, generiert der Compiler den operator== nicht automatisch. std::ranges::sort sieht also eine Klasse, die man zwar vergleichen, aber nicht auf Gleichheit prüfen kann – und bricht mit einem kryptischen Compiler-Fehler ab.

Aua, der operator<=> wurde doch eingeführt, weil er eben direkt „Kleiner als“, „Gleichheit“ und „Größer als“ ausdrücken kann, und da muss man explizit die Gleichheit nochmals implementieren? Kein Wunder, wenn C++ immer ins Hintertreffen gerät – das ist unlogisch. Früher wusste man, dass operator== und operator< zu implementieren ist.

Danke für den Hinweis.

[Anon-81275]

Ja, ich bin auch kein C++-"Stammspieler", aber ich sehe das so ähnlich wie du. Ich glaube, das ist so etwas ähnliches wie Ballast, der einfach die Komplexität erhöht. Mir fällt jedenfalls spontan kein sinnvoller Use-Case ein.

[Quiche Lorraine]

Danke Leute, ich habe die Operatoren <=> und == definiert und damit funktioniert das std::ranges::sort auch.

[Quiche Lorraine]

@john-0 sagte in Probleme mit std::sort, std::ranges::sort und eigenem < Operator:

Kein Wunder, wenn C++ immer ins Hintertreffen gerät – das ist unlogisch.

Uff, ehrlich gesagt juckt mich das nicht.

Das muss man wissen, man könnte es auch als eine Macke bezeichnen, aber die Schönheit eine Sprache ist eine Sache, die Stilblüten der Benutzer eine andere.

Ich sehe da gerade eine Design-Pattern Seuche.

class UART_Base
{

}
class UART_1 : public UART_Base
{
  UART_1* GetInstance()...
}

UART_BASE* GetInstance(int Mode)
{
   if (Mode == 1)
      return UART_1.GetInstance();
  if (mode == 2)
     return UART_2.GetInstance();
}

Und gerade sehe ich in der Android Welt so eine schöne Mischung aus Java und Kotlin. Gradle ist so lahm wie eh und je. Man schießt gerne mit Kanonen auf Spatzen in dem man eine z.B. eine Kommunikation IO in einen eigenen Prozess auslagert und mittels Sockets darauf zugreift.

[Anon-81275]

@Quiche-Lorraine sagte in Probleme mit std::sort, std::ranges::sort und eigenem < Operator:

die Stilblüten der Benutzer eine andere.

... für mich ist das eine pauschale Abwertung. Es hat doch nicht mehr mit Geschmack zu tun, wenn eine Sprache derart verschlimmbessert wird, dafür gibt es sogar objektive Kriterien bzw. Metriken.

Wenn es für ein Feature keinen Mehrwert gibt, aber ich nun für das gleiche Ergebnis mehr als vorher schreiben muss, oder Bestandscode unnötig legacy wird, dann verfehlt das Feature den Zweck. Also, höherer Aufwand, gleicher Nutzen.

Ja, nicht jeder mag Rindfleisch, aber deshalb leben Vegetarier auch nicht gesünder.

Sorry, musste das einmal rauslassen.

[Schlangenmensch]

@john-0 Es gibt Fälle, bei denen Ordering und Gleichheit nicht wirklich passend sind.
Da ich gerade nicht am Computer bin, nur ein Link anstelle einer Erklärung: https://iifx.dev/en/articles/457613117/mastering-c-20-comparisons-aligning-spaceship-operator-and-equality-for-your-point-class

[Anon-81275]

@Schlangenmensch 503 Fehler, wenn ich auf den Link klicke...

Ich verstehe nicht, in welchen Fällen man den Kontrakt der Quasiordnungsrelation (Reflexivität und Transitivität) aufgeben sollte - also wann es sinnvoll wäre, dass a < b und b > a, a != b nicht gälte.

[Anon-81275]

Ah, der Link funktioniert jetzt, im zweiten Anlauf, doch.

Man kann nun also auch definieren, dass zwei Punkte im euklidischen Raum gleich sind, obwohl sich ihre x- und y-Koordinaten unterscheiden (das scheint in bestimmten math./physikal. Kontexten wohl auch sinnvoll zu sein).

[*john 0]

@Schlangenmensch sagte in Probleme mit std::sort, std::ranges::sort und eigenem < Operator:

@john-0 Es gibt Fälle, bei denen Ordering und Gleichheit nicht wirklich passend sind.

Wenn man sich auf diese Schiene begibt, dann öffnet man die Büchse der Pandora. Bisher war das in C++ so, dass operator<, operator> und operator== sich auf die gleiche Ordnungsrelation bezogen. Im Beispiel wurden ints benutzt, d.h. eine Teilmenge von $\mathbb{Z}$ auf der eines keine Mehrdeutigkeit der Vergleichsoperatoren gibt. Wenn man hingegen Elemente aus $\mathbb{C}$ hat, dann gibt es darauf nur den Test auf Gleichheit. $(\mathbb{C}, \lVert \, \rVert)\, \mathbb{C}\rightarrow\mathbb{R}$ bildet nun einmal auf eine andere Zahlenmenge ab. std::complex hatte schon immer die Funktion abs, was die Anforderung einer Norm auf std::complex entspricht.

Bei einer Programmiersprache stellt sich dann die Frage was soll dann der operator== vergleichen? Wir der Wert von Foo vergleichen, d.h. in diesem Fall wäre das eindeutig wegen der Teilmenge von $\mathbb{Z}$, oder werden die Objekte vergleichen? Da stellt sich dann die Frage, ob man die Gleichheit der Objekte testet oder deren Äquivalenz, d.h. sind die Objekte wirklich gleich d.h. dasselbe Objekt im Speicher, oder haben sie nur dieselben Werte?

[Anon-81275]

Oder auch, um mal ein konkreteres Beispiel zu nennen, als irgendwelche abstrakten Zahlen - jedes Auto hat eine PS-Anzahl und ein Gewicht. Nun kann aber Fahrzeug A mit 100 PS und 1000 kg genauso schnell auf 100 beschleunigen, wie Fahrzeug B mit 200 PS und 2500 kg... Nur, es wird sich in der Praxis aber vermutlich derjenige Kunde beschweren, welcher zwar einen schwarzen 911er bestellt hatte, stattdessen aber einen gelben VW Polo geliefert bekommt. Und womöglich auch noch betrieben per Strom... also DER Stilwidrigkeit des Dogmatismus schlechthin.