Fehler C2672 "operator __surrogate_func": keine übereinstimmende überladene Funktion gefunden

Verkürzt sieht der Code so aus:

#include <algorithm>
#include <vector>
#include <iostream>

class Foo {
public:
    int value;

    Foo(int v) : value(v) {}


    bool operator<(const Foo& other) const {
        return value < other.value;
    }
};


/*
bool operator<(const Foo& lhs, const Foo& rhs) { // Kompiliert nicht
    return lhs.value < rhs.value;
}
*/



int main() {
    std::vector<Foo> vec = { Foo{5}, Foo{1}, Foo{9}, Foo{3} };

    //std::sort(std::begin(vec), std::end(vec));  // (1) Kompiliert
    std::ranges::sort(vec);                   // (2) Kompiliert nicht
    /*
    std::ranges::sort(vec, [](const Foo& f1, const Foo& f2) {
        return f1 < f2;
    });                                         // (3) Kompiliert
    */


    for (const auto& f : vec) {
        std::cout << f.value << ' ';
    }
}

Das Problem taucht sowohl in VS, GCC, und CLANG auf.

Punkt (1) kompiliert und ist mein aktueller Stand, welcher ich auch so lasse.

Punkt (2) kompiliert nicht.

Punkt (3) war so mein erste Hack-Test.

Kommentiere ich den < Operator mit zwei Parametern ein, so kompiliert das Programm nicht mehr.

Rein aus Interresse, was geht hier schief?

Ja, das kommt sehr häufig vor. Wenn du std::ranges::sort für eine Liste von eigenen Objekten aufrufst, muss die Funktion die Objekte miteinander vergleichen können. Dafür benötigt sie Zugriff auf den Kleiner-als-Operator (<) oder eine benutzerdefinierte Vergleichsfunktion. [1]
Wenn die Datenfelder deiner Klasse privat (private) sind, musst du diesen Operator oder die Funktion oft als friend deklarieren, damit er auf die internen Werte zugreifen darf.

Warum friend bei std::ranges::sort wichtig ist

Standardmäßig nutzt std::ranges::sort den Operator <. In modernem C++ (ab C++20) nutzt man hierfür idealerweise den Drei-Wege-Vergleichsoperator (<=>), auch bekannt als Spaceship-Operator.
Da dieser Operator außerhalb der Klasse als freie Funktion agiert oder die Argumente symmetrisch behandeln muss, benötigt er das Schlüsselwort friend, um die privaten Attribute der Klasse zu lesen.

Vereinfacht gesagt: Dein compare op muss unabhängig vom Kontext der Klassen verwendet werden können, aber gleichzeitig Zugriff auf die Member der Klasse erhalten.

Du musst den neuen operator<=> definieren! Dann übersetzt das auch problemlos.

Ja, das sollte man auch beachten.

#include <algorithm>
#include <vector>
#include <iostream>

class Foo {
        int value;
public:
        explicit Foo (const int v) : value(v) {}

        auto operator<=> (const Foo& rhs) const = default;

        int get() const {
                return this->value;
        }
};

int main() {
    std::vector<Foo> vec = { Foo{5}, Foo{1}, Foo{9}, Foo{3} };

    std::ranges::sort(vec);

    for (const auto& f : vec) {
        std::cout << f.get() << ' ';
    }
    std::cout << "\n";
}

eingebe übersetzt er es problemlos, und es gibt ein richtiges Ergebnis. Wenn ich versuch den operator<=> selbst zu schreiben, wirft er mir einen Fehler. Momentan hadere ich damit, dass ich das nicht nachvollziehen kann.

dass der Compiler bei deinem selbstgeschriebenen operator<=> streikt, liegt an den strengen Concepts von C++20 Ranges.
Damit ein Typ mit std::ranges::sort sortiert werden kann, muss er das Concept std::sortable erfüllen. Dieses baut wiederum auf std::totally_ordered auf. Das bedeutet für dich: Ein Typ ist für Ranges nur dann sortierbar, wenn er sowohl eine Ordnung (<) als auch eine Gleichheit (==) besitzt.

Warum funktioniert = default?

Wenn du auto operator<=>(const Foo&) const = default; schreibst, ist der Compiler so nett und generiert für dich implizit auch gleich den passenden Gleichheitsoperator (operator==) mit. Damit ist die Bedingung für std::totally_ordered erfüllt.

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.

Die Lösung

Wenn du den Spaceship-Operator selbst implementierst, musst du den operator== entweder ebenfalls manuell schreiben oder ihn separat via = default anfordern:

class Foo {
    int value;public:
    explicit Foo(const int v) : value(v) {}

    // 1. Dein manueller Spaceship-Operator für die Ordnung
    auto operator<=>(const Foo& rhs) const {
        return this->value <=> rhs.value;
    }

    // 2. WICHTIG FÜR RANGES: Der Gleichheitsoperator (kann defaulted werden)
    bool operator==(const Foo& rhs) const = default; 

    int get() const { return this->value; }
};

Sobald der operator== vorhanden ist, kompiliert dein Code auch mit der manuellen Variante fehlerfrei.

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.

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.