3. Problem mit einer verketteten Liste in VS6.0

Problem mit einer verketteten Liste in VS6.0

  • K

    Hallo zusammen,

    ich versuche gerade ein Objekt Town in einer selbst geschriebenen verketteten Liste abzulegen. Leider ohne erfolg, die Methode zum anhängen an die Liste erwartet einen Standard-Konstruktor den ich aber nicht vorgesehen habe. Vorgesehen ist ein überladener Konstruktor mit einem String als Argument. Ich weiß allerdings nicht wie die Funktion zum anhängen an eine Liste auf die Idee kommt den Standard-Konstruktor nutzen zu wollen (den es ja garnicht gibt). Der Code findet sich unter http://www.planet-minich.de/Conny.rar
    Vielleicht kann mir da jemand helfen...

    Vielen Dank,
    Matthias

    0
  • P

    Offensichtlich erzeugst du irgendwo ein Town objekt mit
    dem Standard Konstruktor. Town t, oder Town *t = new Town(); z.B.
    Evtl. fehlt auch der Copyconstructor, aber dann würde er wohl
    net wegen dem Standard Konstruktor meckern.

    Alternativ std::list

    Devil

    0
  • K

    da liegt ja genau das problem, ich finde es einfach nicht. Keinen blassen Schimmer...
    Übrigens versuche ich das hier "von Hand" um zu kapieren wie man sowas programmiert. Mit nem Template ist das sicher einfacher, aber nicht so lehrreich.

    Gruß,
    Matthias

    0
  • O
     

    ListElement::ListElement(const Town& newdata)
{
	next = NULL;
	previous = NULL;
	this->data = newdata;
}

    Hier passiert in Bezug auf data (das ist die Town) Folgendes: Erst wird die Town default-konstruiert, weil in der Initialisierungsliste nichts Anderes für sie angegeben wird. Dann weist du ihr über den Zuweisungsoperator eine andere zu. Was du willst, ist sie direkt über den Kopierkonstruktor zu initialisieren - such dafür einfach mal nach Initialisierungslisten.

    Ansonsten brauchen sowohl List als auch ListElement dringend eigene Kopierkonstruktoren und Zuweisungsoperatoren, oder sollten diese zumindest verbieten, und wahrscheinlich sollte dafür das 'virtual' vor den Destruktoren weg. Du hast ja eigentlich nicht nach Stilkritik gefragt, aber das ist mir gerade aufgefallen 🙂

    0
  • K

    gut, ich habe jetzt den Konstruktor der Klasse ListElement folgendermaßen verändert:

    ListElement::ListElement(const Town& newdata):next(NULL), previous(NULL), data(newdata)
{
	next = NULL;
	previous = NULL;
	this->data = newdata;
}

    der Compiler-Fehler tritt nicht mehr auf. Gehe ich recht in der Annahme, dass ich auch einen Default-Konstruktor für die Klasse Town hätte einsetzen können in dem alle Variablen auf NULL bzw. einen leeren String gesetzt werden?

    Dummerweise kommt es jetzt zu einer Zugriffsverletzung beim Aufruf der print()-Funktion eines Elements der Liste. Diese Funktion soll das in dem Listenelement enthaltene Town-Objekt mit dem Namen "data" ausgeben. Dabei kommt es zum Fehler, da data scheinbar leer ist... Stellt sich die Frage warum??

    Gruß,
    Matthias

    P.S.: Copy-Konstruktor für ListElement kommt doof, weil doch nie zwei wirklich gleiche ListElement-Objekte existieren dürfen, oder? Weil dann wäre es ja keine verkettete Liste...

    0
  • O

    klayman schrieb:

    ListElement::ListElement(const Town& newdata):next(NULL), previous(NULL), data(newdata)
{
	next = NULL;
	previous = NULL;
	this->data = newdata;
}

    Und wozu ist alles zwischen { und } gut?

    der Compiler-Fehler tritt nicht mehr auf. Gehe ich recht in der Annahme, dass ich auch einen Default-Konstruktor für die Klasse Town hätte einsetzen können in dem alle Variablen auf NULL bzw. einen leeren String gesetzt werden?

    Ja. Aber uninitialisierte Zustände sollte man vermeiden, wenns nicht zu sehr weh tut. In dem Fall geht's doch so auch gut 🙂

    P.S.: Copy-Konstruktor für ListElement kommt doof, weil doch nie zwei wirklich gleiche ListElement-Objekte existieren dürfen, oder? Weil dann wäre es ja keine verkettete Liste...

    Eben darum sollte man, wenn kein sinnvolles Kopieren möglich ist, es zumindest verbieten (Kopierkonstruktor und Zuweisungsoperator privat deklarieren und nie implementieren). Sonst kommen nämlich im Falle eines Falles die automatisch generierten Versionen zum Zuge, und dann knallt es richtig. -> Lieblingslehrbuch zum Thema automatisch generierte Elementfunktionen

    0
  • K

    gut, das ist soweit verstanden, die copy-konstruktoren hab ich jetzt auch verboten. Bleibt aber immernoch der Fehler beim Ausgeben des Town-Objekts in einem ListElement. Scheinbar steht dort NULL drinne, obwohl ich es gesetzt habe (zumindest glaube ich das ;-))

    Danke,
    Matthias

    0
  • K

    *nachobenrück*
    hat jemand noch einen hilfreichen Tipp für mich?

    Vielen Dank,
    Matthias

    0
Anmelden zum Antworten