bei meinem kleinen Spiel ruft eine Klasse den Konstrukor einer weiteren auf. Dabei werden einigen Pointer auf weitere Objekte gespeichert.
Wenn ich mit Visual Studio das Programm in der letzten Zeile des besagten Konstruktors anhalte, stimmen alle Membervariablen der Pointer-Objekte. Wenn ich aber das Programm einen Schritt weiterlaufen lasse, bis zum Befehl, der nach dem Konstruktoraufruf drankommt, dann sind plötzlich alle Variablen Mist. (Übrigens bei jedem Versuch der identische Mist)

Hier ein Bild zur Veranschaulichung:
http://s14.directupload.net/file/d/2726/m4rrvpc7_png.htm

Zwischen den beiden Screenshots wurde also kein eigener Code von mir abgearbeitet. Liegt es vielleicht an dem Vektor, der die rot markierten Zeiger speichert?
Was könnte beim Beenden des Konstruktors schief laufen?

Danke!
Knobbers

Die Großen Drei?

https://secure.wikimedia.org/wikipedia/de/wiki/Dreierregel_(C%2B%2B)

*insblaueschieß*

@volkard
17891602 entspricht im hexadeziemalsystem 1110112. Das kommt in der Liste nicht vor.

@volkard
17891602 entspricht im hexadeziemalsystem 1110112. Das kommt in der Liste nicht vor.

0xFEEEFEEE : Used by Microsoft's HeapFree() to mark freed heap memory

...nicht?

@volkard
17891602 entspricht im hexadeziemalsystem 1110112. Das kommt in der Liste nicht vor.

Du sollst doch nicht selber umrechnen. In der IDE im Debugger rechte Maustaste auf die Anzeige der Variablen und auf hexadezimale Anzeige umstellen, hatte gehofft, sowas gibt es.
Und per Hand müßtest Du das Vorzeichen beachten. Es ist ja -17891602.
Als rechnest Du http://lmgtfy.com/?q=-17891602+%2B+2^32+to+hex

Aber du speicherst nicht zufällig Zeiger auf die Objekte, bevor die in den Vector kommen?

Äh doch mach ich? Hab aber nich ganz verstanden warum sich dann was genau ändern soll.

@volkard:
Achso danke und was sagt mir der Fehler dann, bzw. was hab ich dann falsch gemacht?
btw cooles Programm, lmgtfy^^

@volkard:
Achso danke und was sagt mir der Fehler dann, bzw. was hab ich dann falsch gemacht?

Tja, leider habe ich keine Ahnung. Ich weiß nur, aß mir 0xfeeefeee nicht passiert.
Aber jetzt wissen Knobbers, elise und Caligulaminus, daß auf dem Speicherbereich vermutlich HeapFree() aufgerufen wurde und knacken das Problem. :xmas1:

äh wie jetz? wie kommst du auf 0xFEEEFEEE? Ich hab das auf so einer Seite im Internet umrechnen lassen. Und was würde das dann bedeuten, wenn es freed heap memory wäre?

guck mal deinen screen genau an...

das du auf speicher zugreifst, der schon frei gegeben wurde...

Und genau das war meine Vermutung
Hier zur Veranschaulichung:

#include <iostream>
#include <vector>
using namespace std;

struct Test {
    bool a, b;
    int c;
    Test(bool a, bool b, int c)
     : a(a), b(b), c(c)
    {}
};

ostream& operator<<(ostream &os, Test const& t) {
    os << t.a << ' ' << t.b << ' ' << t.c;
    return os;
}

void assign_and_append(Test *& tp, bool a, bool b, int c, vector<Test>& tv) {
    Test t(a, b, c);  // temporäres Objekt
    tv.push_back(t);  // Legt eine _Kopie_ von t in den Vektor
    tp = &t;          // Weist dem Zeiger die Adresse des temporären Objektes zu
} // Hier wurde t zerstört, tp zeigt auf freigegebenen Speicher!

int main() {
    vector<Test> tv;
    Test *t1, *t2;
    assign_and_append(t1, false, true, 12340, tv);
    t2 = &tv[0];
    cout << *t1 << endl << *t2 << endl << tv[0] << endl;
}

Zu dem Zeitpunkt, an dem der Zeiger auf freigegebenen Speicher zeigt, ist die Instanz des Objektes, auf das er eigentlich zeigen sollte, laut Debugger noch vorhanden!

Kein Debugger kann dir sagen, ob an einer bestimmten Speicherstelle ein bestimmtes Objekt existiert oder nicht.
Alles was dir mitgeteilt wird ist: falls an der Stelle ein bestimmtes Objekt existiert, dann hat es den angezeigten Inhalt.

[code]

schlacht::schlacht(...){
     (...)
     //die Adresse einer Instanz der Klasse "einheit" zuweisen
     test_pointer_auf_einheit = sArmee->getEinheit(0); 

     //die Adresse einer Instanz der Klasse "feld" zuweisen
     test_pointer_auf_einheit->test_pointer_auf_feld = sMap.getFeld(0,0);

     //einen bool-Member der Instanz ändern
     sMap.getFeld(0,0)->belegt = false;

}

//diese Funktion wird kurz nach dem Konstruktor aufgerufen
void schlacht::aktionenJeFrame(){
    //einheit-zeiger funktioniert, test1 bekommt den richtigen Wert
    int test1 = test_pointer_auf_einheit->pos.x;

    //die Instanz von "feld" existiert noch, test2 wird false
    bool test2 = sMap.getFeld(0,0)->belegt;

    // test3 wird true, der Zeiger funktioniert nicht richtig
    bool test3 = test_pointer_auf_einheit->test_pointer_auf_feld->belegt;

weiteren Member am Ende des Zeigers werden von MSVS als FEEEFEEE angezeigt

Die Instanz der Feld-Klasse, auf die mein Zeiger zeigt, ist also noch vorhanden (Zeile 20). Und trotzdem kann ich sie nicht über den Zeiger ansteuern, der von meiner Einheit-Instanz gespeichert wird (Zeile 23). Habt ihr noch ein paar Ideen auf Lager? Ich weiß echt nicht mehr weiter.

Der Punkt ist doch, dass ich UNMITTELBAR nach Beenden des Konstruktors nicht über den Zeiger "test_zeiger_auf_feld" auf das gewünschte Feld zugreifen kann (per Debugger oder per Code), OBWOHL das Feld exisitert (Zeile 22) sowie die Einheit, welche diesen Zeiger testhalber speichert (Zeile 19).

Zwischen denn letzten Zeilen des Konstruktors und dem Funktionsaufruf von "aktionenJeFrame" ist sonst kein Code.

Was genau liefert denn "sArmee->getEinheit(0)" bzw. "sMap.getFeld(0,0)" zurück?

Ich versteh nicht. Willst du den Wert wissen? 0x1235ef4c? Adressen halt.

Th69 schrieb:

lokalen Variable

Was soll lokal sein? Das Feld auf das "test_pointer_auf_feld" zeigt? Wenn das so wäre könnte ich ja nicht wie in Zeile 22 meines Codes drauf zugreifen.

Was soll lokal sein? Das Feld auf das "test_pointer_auf_feld" zeigt? Wenn das so wäre könnte ich ja nicht wie in Zeile 22 meines Codes drauf zugreifen.

Genau, das Feld. Wenn dein sMap() intern ein Array speichert, und du dann sowas machst:

Feld f = Array[0][0];
return &f;

Dann liegt in deinem test_pointer eine Adresse auf ein temporäres Objekt-Bumm!
Und darauf zugreifen kannst du natürlich - sowas nennt sich "undefiniertes Verhalten". Es kann gut gehen, aber auch nicht, Du kannst auch plötzlich nackt in der U-Bahn stehen...
Dass die Werte plötzlich nicht mehr stimmen deutet sehr stark auf undefiniertes Verhalten hin...

Ich mach glaub ich sowas ähnliches, wie du vermutet hast. Ich speicher die Felder in sMap in einem Vektor.

for (int i = 0; i < 100; i++){
     for (unsigned int j = 0; j < 100; j++){
	     felder.push_back(feld(i,j)); //std::vector<feld> felder
     }
}

Wenn ich testhalber Felder außerhalb des Vektors anlege und ihre Adresse verteile, dann funktioniert es. Aber wieso funktioniert es nicht mit dem Vektor? Dieser ist ja ein fester sMap-Member. Der dürfte ja nicht einfach plötzlich seinen Inhalt freigeben. Hat das irgendwas mit seiner variablen Größe zu tun oder so?

Siebenweger schrieb:

Du kannst auch plötzlich nackt in der U-Bahn stehen...

Davor hat mich kein C++-Tutorial gewarnt!!!