Methode kennt Objekt nicht



  • Hallo,

    arbeite derzeit an einem größeren Projekt und benutze zum Testen Turbo C++.

    vorab: der Fehler entsteht nicht in G++.

    Ich habe das Problem jetzt nach mehreren Tagen ausfindig gemacht, finde aber keinen Ansatz.

    Eine (bzw. mehrere) Methoden, die ich aufrufe, haben keinen Bezug mehr zum Objekt insofern, dass "this" den Wert NULL hat.

    Andere Methoden der Klasse funktionieren einwandfrei.

    Ich habe bereits versucht, die Methoden umzubenennen, die Deklarationen zu verschieben, direkt in der Deklaration den Quellcode einzufügen. Überall keinen Bezug zum Objekt.

    Der Quellcode ist nicht fehlerhaft und im Grunde auch nichts besonderes, nur eine Return-Anweisung.

    Ich bin hier mit meinem Latein am Ende, hoffe jemand von euch weiß, was sich da machen lässt.

    Hier nochmal eine der fehlerhaften Methoden:

    int Karte::getType(int x,int y)
    {
    	return aaFeldArray[x][y].m_type;
    }
    

    Diese hier hingegen funktioniert:

    int Karte::getKosten(int x,int y)
    {
        return aaFeldArray[x][y].m_Kosten;
    }
    

    mfg
    Manu



  • Hallo

    Das Problem ist doch klar, und irgendwelches Umbenennen oder verschieben bringt da nichts. Irgendwo in deinem Programm rufst du die Methoden über einen Pointer auf der aber NULL ist. Hier mal vereinfacht

    Karte* karte = 0;
    karte->getType(1,2); // In diesem Aufruf ist this = NULL
    

    Das Problem solltest du am leichtesten mit dem [url=http://www.junix.ch/bcb/help/debug.html]Debugger[/cpp] aufindig machen.

    bis bald
    akari



  • So Dumm bin ich ja nun wirklich nicht. >_>

    Ich hab das ganze erst mit dem Debugger herausgefunden.

    Hier mal etwas vom Programmcode:

    void Karte::RegisterObjekt(int x,int y,int ObjektID) //verbuggte Methode
    {
        aaFeldArray[x][y].m_type = ObjektID;
    }
    
    void Karte::setGelaende(int x,int y,int Gelaende) //ich funktioniere!
    {
    	if(Gelaende < g_AnzahlGelaendeTypen)
    	{
    		aaFeldArray[x][y].m_Gelaende = Gelaende;
    		aaFeldArray[x][y].m_Kosten = g_GelaendeKosten[Gelaende];
    	}
    	else
    	{
    		aaFeldArray[x][y].m_Gelaende = g_invalid;
            aaFeldArray[x][y].m_Kosten = g_invalid;
        }
    }
    
    int Karte::LoadMap(string MapName)
    {
    //hier steht anderere Code
    //wie z.b. viele viele male
    setGelaende(a,b,c); //werte aus Datei
    //... alles fein alles fein
    RegisterObjekt(1,1,1); //test --> CRASH
    }
    

    etwas Hauptprogramm:

    Karte dieKarte;
    
    	dieKarte.LoadMap("BERG");
    
    	for(int i=dieKarte.getX()-1;i>=0;i--)
    	{
    		for(int j=dieKarte.getY()-1;j>=0;j--)
    		{
    			gotoxy(i+1,j+1);
    			cout<<dieKarte.getKosten(i,j);
            }
    	}
    	gotoxy(1,dieKarte.getY()+1);
    

    funktioniert einwandfrei!

    aber jetzt das hier:

    dieKarte.getType(1,1);
    

    Bam! Crash. Zugriffsverletzung Bla Bla this=0.

    Nuuuun ja. Wie ich vorhin schon gesagt habe, am Code liegt's nicht.

    Also SO klar ist das Problem dann doch wieder nicht.

    Achja! In dem selben Projekt ist es vorgekommen, dass in einem Constant Int Array plötzlich ganz andere Werte standen als die, die ich im Quellcode definiert habe.

    Und wie ich schon GAAAAANZ OBEN gesagt habe, kompilierte und lief alles EINWANDFREI im G++.
    Ich habe das Projekt auch auf einem anderen Rechner mit Turbo C++ getestet. Gleicher Fehler.

    Hat jemand eine Idee, oder soll ich jetzt alles nur noch mit g++ compilieren? 😕

    -Manu



  • Hallo,

    Das sieht ganz so aus, als ob du irgendwo auf nicht allozierten Speicher zugreifst (schreibend). Das muß nichts mit deiner Klasse zu tun haben. So etwas erzeugt undefiniertes Verhalten und kann sich auch viel später auswirken. Geh einfach mal mit dem Debugger durch den gesamten Code und schau dir deine Pointer, Arrays etc. an.



  • Sieht so aus, ist aber nicht der Fall.
    Sobald das Programm in die Methode springt ist der "this" pointer = NULL, in anderen Methoden funktioniert es ganz normal.

    Glaubt ihr mir jetzt endlich, dass es kein Fehler im Code ist? ES HAT IM G++ DOCH FUNKTIONIERT. 😑

    Ich habe zum Testen ein Feld von 10 mal 10 feldern, die alle mühelos ausgegeben werden. Ein Feld ist eine Klasse mit Datenelementen, die alle Daten mit 0 initialisiert.

    Ich dachte auch erst, dass es daran liegen könnte, dass m_type nicht angelegt wird, da nur die Funktionen verbuggt zu sein scheinen, die darauf zugreifen. Habe ich den Aufruf geändert, kam immernoch der Fehler. Später dann im Debugger bemerkt, dass this = NULL ist und somit alle anderen Klassenvariablen ungültig sind (mit ??? versehen).



  • Hallo

    Glaubt ihr mir jetzt endlich, dass es kein Fehler im Code ist? ES HAT IM G++ DOCH FUNKTIONIERT. 😑

    Das beweist nur das du mit dem G++ mehr Glück mit ungültigem Code hattest als mit dem Borland-Compiler. Denn nur weil etwas läuft heißt das noch lange nicht das es sauber ist. Das Problem bei ungültigem Code mit undefiniertem Verhalten ist nunmal das es auch "gutgehen" kann... und wo anders abstürzt.

    Klar ist jedenfalls das du die besagte Methode über einen Zeiger mit dem Wert NULL aufrufst, und das liegt an deinem Code. Also benutzt endlich den Debugger und schau wo die Methode aufgerufen wird, und verfolg den Aufruf immer weiter zurück.

    bis bald
    akari



  • Leg doch bitte mal dieKarte dynamisch an (mit dem new operator). Hatte solch merkwürdiges Verhalten auch mal mit einen statischen Array gehabt.



  • Reduziere dein Projekt doch mal so weit wie möglich (auskommentieren des anderen Codes) bis es funktioniert.



  • Hallo

    Solches "merkwürdige Verhalten" ist in den meisten Fällen die Folge von ungültigem Code. Und bevor man an Fehler beim Compiler glaubt und irgendwelche obskuren Workarounds einbaut die vielleicht laufen oder auch nicht, sollte man lieber die Ursache im eigenem Quellcode suchen. Ja das ist manchmal hart und nervend, weil man auch Code durchschauen muß bei dem man schwört das er fehlerfrei sei.

    bis bald
    akari



  • ALSO LEUTE.

    Ich geb's auf. Ihr checkt's einfach nicht.
    Ich bin KEIN Anfänger und ich bin NICHT dumm.

    Wer will, der kann die Relevanten Daten des Projekts von mir haben und es selber ausprobieren. Ansonsten verabschiede ich mich von hier, die "Hilfe" muss ich mir nicht weiter geben.

    Also meine email Adresse, falls es hier jemanden gibt, der lesen kann, ist manu-lg@hotmail.de.

    bis denne.



  • Hallo

    Ihr checkt's einfach nicht.

    Wir müßen gar nichts "checken". Das ist dein Projekt, du hast (hoffentich) schließlich den besten Überblick. Es gibt eben Fehler die können auch wir hier im Forum nicht aus ein paar Zeilen Code heraus sofort finden.

    Ich bin KEIN Anfänger und ich bin NICHT dumm.

    Niemand hier hat behauptet das du dumm seist oder ein Anfänger. Alle hier wollten dir ernsthaft mit ihren Wissen helfen.
    Nur es ist dein Problem wenn du unsere Hilfe nicht ernstnimmst. Du wurdest zum Beispiel mehrmals ernsthaft auf Null-Pointer und den Debugger hingewiesen. Mehr können wir dazu eben nicht sagen, ohne wild zu spekulieren.
    Da du aber als einzigstes Ergebnis deines Debuggers herausgefunden hast das this in der Methode NULL ist zeugt nun mal davon das du mit dem Debugger selber wenig Erfahrung hast.

    bis bald
    akari



  • Manu (Gast) schrieb:

    Ich geb's auf. Ihr checkt's einfach nicht.
    Ich bin KEIN Anfänger und ich bin NICHT dumm.

    Check' lieber mal die Kompilereinstellungen (Aufrufkonventionen : __stdcall, __cdecl).

    Dann findest Du den this-pointer auch wieder. Altbekanntes Thema : "Mein Kompiler und die Default's".



  • Hallo

    merker schrieb:

    Check' lieber mal die Kompilereinstellungen (Aufrufkonventionen : __stdcall, __cdecl).

    Dann findest Du den this-pointer auch wieder. Altbekanntes Thema : "Mein Kompiler und die Default's".

    😕 Was haben Aufrufkonventionen mit this-Zeigern zu tun?

    bis bald
    akari


Anmelden zum Antworten