Vergleich von Objekten



  • Eisflamme schrieb:

    was sagt ihr dazu?

    Wieso wir? Ich habe bisher von keinem gelesen, der so eine Universallösung will. Nur du möchtest aus ungenannten Gründen so etwas haben.

    Ich sehe auch keinen wirklichen Sinn darin. Klassen können einen operator== anbieten, wenn es Sinn macht. Das hat auch den Vorteil, dass die Identität eines Objektes gleich mitbestimmt wird. Wenn kein operator== vorhanden ist, macht es evtl. auch keinen Sinn einen Vergleich durchzuführen (bzw. gibt es dann keine Standard-Vergleichskriterien). Dann würdest Du ohne genaue Kenntnis der Klasse einen Vergleichsoperator nutzen, dessen Ergebnis Du überhaupt nicht einschätzen könntest.

    Wenn ich Klassen nutze, die keinen operator== anbieten und ich einen will, beschäftige ich mich genau mit der Klasse und schreibe einen. Das ist auch nicht weniger Arbeit als mich genau mit der Klasse zu beschäftigen und den Universal-operator== zu benutzen.

    Erklär doch lieber Mal, wofür Du so etwas brauchst. Mir scheint, dass das mehr ein Gedankenexperiment ist, als dass es einen tatsächlichen Anwendungsfall gibt.

    Der Sinn hinter der ganzen Sache ist eine Art UnitTest...

    es gibt ein zu erwartendes Objekt (expected) und ein erhaltenes Objekt (received):

    int expected = 5;
    int received = funciton_add(2,3);
    
    if (compare<int>(expected, received) == true) {
        // result = success
    } else {
        // result = failed
    }
    

    Anstelle des int könnte eine ganz andere Klasse stehen, trotzdem sollte der Test herausfinden, ob das resultat der funktion positiv war, also das zu erwartende und das bekommene objekt übereinstimmen

    bool result;
    
    MyClass expected = blubberblah;
    MyClass received = doSomething();
    
    result = compare<MyClass>(expected, received)
    


  • RussianTux schrieb:

    Anstelle des int könnte eine ganz andere Klasse stehen, trotzdem sollte der Test herausfinden, ob das resultat der funktion positiv war, also das zu erwartende und das bekommene objekt übereinstimmen

    Tja, du kannst aber nichts testen, was die Klasse gar nicht kann.



  • Na dann mach doch einfach:

    template<typename T>
    bool compare(const T& lhs, const T& rhs)
    {
        return lhs == rhs;
    } // hierfür eine Funktion zu machen, macht wenig Sinn, weil Du das einfach dort einbetten kannst, wo du die Abfrage machen willst...
    // dennoch schlage ich vor einfach darauf zu vertrauen, dass operator== da ist
    

    und sorge gleichzeitig dafür, dass von jeder Klasse, die für Deine Unit-Tests zur Verfügung stehen soll, Vergleichsoperatoren zur Verfügung stehen.



  • TyRoXx schrieb:

    Tja, du kannst aber nichts testen, was die Klasse gar nicht kann.

    Also... diesen Satz kann ich irgendwie nicht nachvollziehen, ehrlich))))

    Eisflamme schrieb:

    Na dann mach doch einfach:
    dennoch schlage ich vor einfach darauf zu vertrauen, dass operator== da ist
    und sorge gleichzeitig dafür, dass von jeder Klasse, die für Deine Unit-Tests zur Verfügung stehen soll, Vergleichsoperatoren zur Verfügung stehen.

    Ja das hört sich dann doch sinnvoller und günstiger an als dauernd an komplizierten Sachen zu schrauben.

    Nagut, werde ich wohl stets den Vergleichsoperator überladen.

    Danke allen die geholfen haben!



  • RussianTux schrieb:

    TyRoXx schrieb:

    Tja, du kannst aber nichts testen, was die Klasse gar nicht kann.

    Also... diesen Satz kann ich irgendwie nicht nachvollziehen, ehrlich))))

    Der Satz ist aber der Knackpunkt.
    Was ein Objekt "ist", definiert sich dadurch was man über das public Interface damit machen kann, welche Informationen man über das public Interface bekommen kann etc.
    D.h. wenn du zwei "MyClass" Objekte hast, die sich gleich verhalten (gemessen an ihrem public Interface), dann sind die auch gleich.
    D.h. verwende einfach das public Interface um die beiden Objekte zu vergleichen.

    Dass du dazu u.U. für jede Klasse eigenen Code schreiben musst ist klar, ist halt so, Pech.



  • hustbaer schrieb:

    RussianTux schrieb:

    TyRoXx schrieb:

    Tja, du kannst aber nichts testen, was die Klasse gar nicht kann.

    Also... diesen Satz kann ich irgendwie nicht nachvollziehen, ehrlich))))

    Der Satz ist aber der Knackpunkt.
    Was ein Objekt "ist", definiert sich dadurch was man über das public Interface damit machen kann, welche Informationen man über das public Interface bekommen kann etc.
    D.h. wenn du zwei "MyClass" Objekte hast, die sich gleich verhalten (gemessen an ihrem public Interface), dann sind die auch gleich.
    D.h. verwende einfach das public Interface um die beiden Objekte zu vergleichen.

    Dass du dazu u.U. für jede Klasse eigenen Code schreiben musst ist klar, ist halt so, Pech.

    Das ist nicht Pech, das ist unklug und unproduktiv für einen UnitTest stets neuen Code zu schreiben...

    Ich habe einfach beschlossen den Vergleichsoperator dafür zu nutzen, da die Klassen ja sowieso immer meine Sind und somit einfach nur die Operator-Support-Regel eingehalten werden muss



  • Du hast erst noch geschrieben dass du die Klassen nicht ändern kannst.

    Und natürlich heisst "für jede Klasse eigenen Code schreiben" nicht dass du ihn für jeden UnitTest neu schreiben musst -- der Code muss nur irgendwo stehen, und irgendjmd. muss ihn (pro Klasse 1x) schreiben.

    Ggf. kann man ja auch seine eigene Funktion

    template <class T>
    bool UnitTestEquals(T const& lhs, T const& rhs)
    {
        return lhs == rhs;
    }
    

    machen, und dann entsprechend für Typen spezialisieren die keinen passenden operator == haben.


Anmelden zum Antworten