C++ Genug Speicher für new
-
Prüft ihr eigentlich, ob "new" erfolgreich war? Eigentlich müsste man ja bei jedem new den Returnwert auf NULL überprüfen, ist doch viel zu aufwendig oder?
:xmas1:
-
Mr. WasWeißIch schrieb:
Eigentlich müsste man ja bei jedem new den Returnwert auf NULL überprüfen
Wie alt ist dein Compiler?
Normalerweise wirft new eine Exception, wenn nicht genug Speicher bereitgestellt werden kann.
-
und zu der zeit, als new keine exception warf, brauchte man auch nicht zu prüfen. das war so mit win95. new hat nur dann eine exception gworfen, wenn man den ganzen sp4eicher aufgebraucht hat, inclusive dem füllen der auslagerungsdatei bis sie nicht mehr wachsen wollte. und dabei ist win95 mit bluescreen abgeschmiert, es hatte also gar keine bedeutung, ob man selber noch was abgefragt hat.
-
Sicher? Das haben die bei Microsoft doch bestimmt abgetestet.
-
hmmmmmmmm schrieb:
Sicher? Das haben die bei Microsoft doch bestimmt abgetestet.
sicher. win95 war nur erheblich stabiler als win31 aber bei weitem noch sicht so stabil wie winxp.
-
ja ich teste sowas immer
-
Ich teste das auch immer:
int* p = NULL; if( !p = new (nothrow) int ) throw "Nicht genug Speicher!!!!!";
-
Getarnter Troll schrieb:
Ich teste das auch immer:
du solltest noch zum throw return dazu schreiben, damit man sieht, daß die funktion verlassen wird, auch wenn man exception-handling nicht so gewohnt ist. und nicht erst nutzlos auf 0 setzen, um dann in einem riesigen magischen mit zu wenigen klammern ausgestatteten zuweisungsbedingungsausdruck mich zu verwirren.
int* p = new (nothrow) int; if( ! p ) return throw "Nicht genug Speicher!!!!!";
-
Hmmm, ich überlege mir immer. Was macht ihr wenn new fehlschlagen sollte? Wird das Programm abstürzen? Oder bekommt der Anwender die Meldung "Junge kauf dir mehr Speicher" oder so...
-
Das Problem ist das man dann wahrscheinlich auch nicht mehr genug Speicher hat um einen Fehlerdialog anzuzeigen.
-
hmmmmmmmmm schrieb:
Das Problem ist das man dann wahrscheinlich auch nicht mehr genug Speicher hat um einen Fehlerdialog anzuzeigen.
Kann schon sein, dass dies dann wieder möglich ist. Wenn man das std::bad_alloc erst in main() oder nicht wesentlich darüber auffängt ist inzwischen u.U. schon eine Menge Speicher wieder frei geworden.
-
Dieser Thread wurde von Moderator/in kingruedi aus dem Forum Rund um die Programmierung in das Forum C++ verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?Dieses Posting wurde automatisch erzeugt.
-
Optimizer schrieb:
hmmmmmmmmm schrieb:
Das Problem ist das man dann wahrscheinlich auch nicht mehr genug Speicher hat um einen Fehlerdialog anzuzeigen.
Kann schon sein, dass dies dann wieder möglich ist. Wenn man das std::bad_alloc erst in main() oder nicht wesentlich darüber auffängt ist inzwischen u.U. schon eine Menge Speicher wieder frei geworden.
Oder man new't 'nen Standard-Error-Dialog direkt am Anfang - für alle Fälle.

-
Zunächst:
Wieso höre ich hier immer Auslagerungsdatei?
Die gibt's ja wohl nur in den aller seltensten Fällen.Es gibt auch noch die Möglichkeit mit set_new_handler einen new_handler zu definieren, der bei scheitern von new aufgerufen wird. Hier hat man dann die Möglichkeit Speicher freizugeben.
-
templäd schrieb:
Zunächst:
Wieso höre ich hier immer Auslagerungsdatei?
Die gibt's ja wohl nur in den aller seltensten Fällen.falsch. die gibts auf fast jedem windows. auch heute, wo man 1G ram hat, ist sie gut.
Es gibt auch noch die Möglichkeit mit set_new_handler einen new_handler zu definieren, der bei scheitern von new aufgerufen wird. Hier hat man dann die Möglichkeit Speicher freizugeben.
klar hab ich das unter dos gemacht. auf dem 386-er mit nur 4M ram.
win95 hatte die unangenehme eigenschaft, lange vor dem verbrauchen des allerletzen bytes die grätsche zu machen. wenn man nur noch 50M frei hatte, wurde es kritisch. bei 10M war der tod gewiß. und irgendwo bei 0 erst würde der newhandler greifen. auch das vorherige allokieren eines fehlerdielaogs hilft nix, da es lange vor dem letzten byte kaputtgeht.