Kein Speicher mehr... aber wieso?
-
Ich habe hier folgenden Code:
int** TestDoppelInt = new int*[Size]; for(int i = 0; i<Size; ++i) { TestDoppelInt [i] = new int(i);//funktioniert wunderbar } Object_2D** LimitObjects = new Object_2D*[Size]; try { LimitObjects[0] = new Object_2D();//geht auch } catch (bad_alloc& ba) { cout << ba.what() << endl; } try { LimitObjects[1] = new Object_2D();//wirf immer exception "bad allocation" } catch (bad_alloc& ba) { cout << ba.what() << endl; } //Falls nützlich: //sizeof(Object_2D) = 44 //Size = 100, aber auch schon mit 2 und 10 erfolglos getestet.Ich bekomme immer ein exception "bad allocation" beim zweiten try-catch block.
Ich kann aber nicht erkennen wieso. Hab ich hier was übersehen?Hier noch was im Outputfenster kommt:
HEAP[The 2D Game.exe]: ZwAllocateVirtualMemory failed c0000018 for heap 00130000 (base 0013A000, size 00130000)
First-chance exception at 0x77616fe9 in The 2D Game.exe: 0xC0000005: Access violation reading location 0x0013a657.
First-chance exception at 0x75eeb727 in The 2D Game.exe: Microsoft C++ exception: std::bad_alloc at memory location 0x0037fa18..
-
Das könnte auch am Konstruktor von Object_2D liegen.
-
Ok, hab den Constructor minimiert und nun geht's.
Danke, jetzt weis ich wenigstens wo suchen muss
Dann werd ich jetzt erstmal stückweise nachsehen was ich da verbockt hab.
-
Andere Frage: Warum kein std::vector?
-
HighLigerBiMBam schrieb:
Andere Frage: Warum kein std::vector?
Hab's auf die schnelle zufuß gemacht.
Jetzt hab ich den std::vector benutzt hilft aber auch nix, weil der fehler ja im Konstruktor steckt.Der Fehler lag in dieser Zeile
GetDIBits(hDC, LoadedBitmap, 0, 16, pPixelData, &bmInf, DIB_RGB_COLORS)Weil ich zum erstenmal eine Datei geladen habe die nicht 16 sondern 14 Breit ist. Hab die 16 vergessen durch eine Variable zu ersetzt und dann den Salat.
Nee, nee, nee wegen sowas hab ich ne Ewigkeit gesucht, nur weil der GetBIBits Rückgabewert trotzdem != 0 ist, wenn die Breite nicht stimmt.Danke für eure Mühe!
-
Die Höhe, nicht die Breite.
Und wieso sollte GetDIBits in dem Fall nicht != 0 zurückgeben? Es kann ja 14 Zeilen kopieren wenn 14 da sind, auch wenn du 16 haben wolltest.
-
Klar die Höhe, weil Anzahl der horizontalen Linien. Hätte ich erst gemerkt wenn ich nicht-quadratische Bitmaps genommen hätte. Danke.
Ja, der Rückgabewert entspricht den erfolgreich gelesenen Linien.
Hab wohl irgendwie noch im Kopf gehabt das die Funktion 0 zurück gibt. Bzw. ich habe es fälschlicherweise als "Fehlschlagen" interpretiert, wenn weniger gelesen wird als gefordert.