Problem mit Copyconstructor
-
Hallo,
ich versuche ich gerade an einer verketten Liste und möchte nun den Copyconstructor überschreiben. Dazu habe ich folgendes geschrieben:List::List(const List& Src) :List() { for (int i = 0; i < Src.mLen; i++) { pushback(Src[i]); } }
Leider funktioniertt das so wohl nicht. Beim Zugriff auf Src bekomme ich schon von IntelliSence angezeigt das was nicht stimmt.
Kein "[]"-Operator stimmt mit diesen Operanden überein.
Mir ist nicht klar was diese Meldung zu bedeuten hat, denn den Operator habe ich definiert.
double& List::operator[](int Index) { int counter = 0; ListNode *current = mFirst; do { if (counter == Index) { return current->mValue; } current = current->mNext; ++counter; } while (current != nullptr); throw "Index außerhalb des gültigen Bereichs"; }
Ich nehme an dass es igrendwie mit Zeiger bzw. Referenzen zu tun hat. Ich finde das noch recht verwirrend, da ein & nach einem Datentyp und davor stehen kann. Es kann aber auch vor dem Variablennamen stehen. Verwirrend
Vielleicht kann mir jemand auf die Sprünge helfen.
Viele Grüße
Thorsten
-
Dein
Src
ist vom Typconst List&
, du hast aber nur einenoperator []
für non-constList
...
-
Hallo,
ich checks nicht...
Wenn ich Deine Antwort richtig verstehe muss ich noch einen weiteren Operator überladen.
Leider ist mir nicht klar welcher das sein soll, da ich im aktuellen Fall das Problem nicht ganz durchschaue. Ich will ja lediglich über ein Index auf Src lesend zugreifen.
Ansich funktioniert der [] Operator ja auch. Warum klappt der Zugriff nun nicht mehr nur weil da const davor steht? const kennzeichnet ja nur dass der Wert nicht verändert werden kann.Viele Grüße
Thorsten
-
Auf einem const Objekt können nur const Methoden aufgerufen werden...
-
Du benötigst noch
const double& List::operator[](int Index) const // bzw. double List::operator[](int Index) const
Stichwort: const correctness
-
Deine Implementierung ist übrigens äußerst ineffizient, es gibt Gründe, wieso std::list kein operator[] anbietet...
Besser eignen sich Iteratoren.
-
eclere schrieb:
Hallo,
ich checks nicht...
Wenn ich Deine Antwort richtig verstehe muss ich noch einen weiteren Operator überladen.
Leider ist mir nicht klar welcher das sein soll, da ich im aktuellen Fall das Problem nicht ganz durchschaue. Ich will ja lediglich über ein Index auf Src lesend zugreifen.
Ansich funktioniert der [] Operator ja auch. Warum klappt der Zugriff nun nicht mehr nur weil da const davor steht? const kennzeichnet ja nur dass der Wert nicht verändert werden kann.Auch wenn die Lösung hier schon beschrieben wurde, nochmal eine kurze Erklärung, weshalb das so nicht funktioniert:
Dein Copy Constructor
List::List(const List& Src) : List()
verspricht die übergebene Liste nicht zu verändern (constList& Src
), das bedeutet du kannst vonSrc
nur Methoden aufrufen, die ebenfalls versprechen das Objekt nicht zu verändern (Methoden die alsconst
deklariert sind). Das ist bei der Methodedouble& List::operator[](int Index)
jedoch nicht der Fall. Diese kündigt dem Compiler durch das Fehlen vonconst
an "ich verändere das Objekt (vielleicht)", daher wird deineconst
-Zusicherung fürSrc
verletzt.Finnegan
-
Hallo,
vielen Dank für die Infos. Ich bin etwas weiter und schlauer
Viele Grüße
Thorsten
-
Nathan schrieb:
Deine Implementierung ist übrigens äußerst ineffizient, es gibt Gründe, wieso std::list kein operator[] anbietet...
Besser eignen sich Iteratoren.Moechte ich nochmal hervorheben. Ganz bloede Idee, vor allem, weil du dich sowieso von Node zu Node hangeln koenntest.
-
Kellerautomat schrieb:
Nathan schrieb:
Deine Implementierung ist übrigens äußerst ineffizient, es gibt Gründe, wieso std::list kein operator[] anbietet...
Besser eignen sich Iteratoren.Moechte ich nochmal hervorheben. Ganz bloede Idee, vor allem, weil du dich sowieso von Node zu Node hangeln koenntest.
Dies war halt Teil der Aufgabe. Ich nehme an um auf Probleme der Art zu stoßen, wie sie auftraten
So weit ich weiss braucht man generell auch keine eigene verkettete Liste mehr schreiben. Gibts alles schon fertig. Aber man muss es wohl mal gemacht haben...oder so.