The secret of while( int i = getValue() )

Nexus

Shade Of Mine schrieb:

aber new wird nicht fehlschlagen...

Warum nicht?

Shade Of Mine

Nexus schrieb:

Shade Of Mine schrieb:

aber new wird nicht fehlschlagen...

Warum nicht?

moderne systeme machen lazy memory commit - sprich sie allokieren den speicher erst dann wenn du ihn brauchst (nicht wenn du sagst dass du ihn haben willst).

ergo gibt es praktisch nur dann ein new fehler wenn das system gerade dabei ist den swap bereich zu vergroessern. das und natuerlich ungueltige groessen angaben sind die einzigen situationen wo moderne systeme new fehlschlagen lassen.

Dravere

Shade Of Mine schrieb:

moderne systeme machen lazy memory commit - sprich sie allokieren den speicher erst dann wenn du ihn brauchst (nicht wenn du sagst dass du ihn haben willst).

Was verstehst du unter moderne Systeme? WinXP SP3 gehört da wohl nicht dazu? Der folgende Code führt bei mir ziemlich schnell zu einem bad_alloc:

int main()
{
  for(;;)
  {
    new int[100000000];
  }

  return 0;
}

Oder hab ich an deiner Erklärung etwas missverstanden?

Grüssli

CodeFinder

Dravere schrieb:

Der folgende Code führt bei mir ziemlich schnell zu einem bad_alloc:
int main()
{
  for(;;)
  {
    new int[100000000];
  }

  return 0;
}
Oder hab ich an deiner Erklärung etwas missverstanden?

Shade Of Mine schrieb:

das und natuerlich ungueltige groessen angaben sind die einzigen situationen wo moderne systeme new fehlschlagen lassen.

Shade Of Mine

Nein, Lazy Commit wird verwendet, aber bei einigen Einstellungen wird die allokierte Page durch einen schreibzugriff zwingend commitet. zB bei Buffer Overflow Checks und dergleichen.

Teste mal folgenden Code:

#include<stdlib.h>

int main() {
	int i=0;
	void* p;
	while(p=malloc(1024)) {
		++i;
	}
	return i;
}

Da hast du keine moeglichen Probleme mit default Ctors und aehnlichen schreibzugriffe.

Konnte das zumindest gerade unter Ubuntu und Vista wieder bestaetigen dass das verhalten immernoch so ist...

Dravere

@CodeFinder,
Das ist aber eine gültige Grössenangabe. Zähle ruhig nochmals die Nullen nach

@Shade Of Mine,
Also zum einen ging es ja ursprünglich um ein anderes Beispiel, welches angeblich nie abbrechen tut. Aber auch dieser von dir präsentierter Code, bricht bei mir ab: VS 8 SP1, WinXP SP3

Grüssli

hustbaer

@Dravere:
Moderne Systeme committen zwar beim malloc/new noch keinen Speicher, sehrwohl aber wird Adressraum reserviert.
Und wenn die max. 4GB auf "flach" adressierenden 32 Bit Systemen weggelutscht sind, dann is halt aus.

Ich schreibe absichtlich "committen keinen Speicher". Ob Speicher reserviert wird oder nicht kann ich nicht sagen. Ich hoffe schon, wäre ein hübsches Roulettespiel wenn nicht

camper

hustbaer schrieb:

@Dravere:
Moderne Systeme committen zwar beim malloc/new noch keinen Speicher, sehrwohl aber wird Adressraum reserviert.
Und wenn die max. 4GB auf "flach" adressierenden 32 Bit Systemen weggelutscht sind, dann is halt aus.

Ich schreibe absichtlich "committen keinen Speicher". Ob Speicher reserviert wird oder nicht kann ich nicht sagen. Ich hoffe schon, wäre ein hübsches Roulettespiel wenn nicht

Was heißt das denn nun? In Bezug auf die Ausführung eines Programmes.

Shade Of Mine

camper schrieb:

Was heißt das denn nun? In Bezug auf die Ausführung eines Programmes.

Dass du bei

char* p = new char[n];
*p=1;

eine Access Violation bekommen kannst.

Mein Code lief bei mir unter Vista und Ubuntu komplett durch und hat die Kiste gefreezt bis ich es gekillt hatte. Aber das ist natuerlich alles implementierungsabhaengig.

Siehe auch man: malloc unter "Bugs"

pumuckl

Shade Of Mine schrieb:

Dass du bei

char* p = new char[n];
*p=1;

eine Access Violation bekommen kannst.

Kann man? Das wäre ja ziemlich grausig, da man dann ja nie sicherstellen kann dass nach einem scheinbar erfolgreichen new die Zugriffe auf den Zeiger auch problemlos ablaufen...

Shade Of Mine

pumuckl schrieb:

Kann man? Das wäre ja ziemlich grausig, da man dann ja nie sicherstellen kann dass nach einem scheinbar erfolgreichen new die Zugriffe auf den Zeiger auch problemlos ablaufen...

Das ist die Quintessenz der letzten 10 Postings hier im Thread...

hustbaer

Tim schrieb:

Siehe auch man: malloc unter "Bugs"

Danke für den Hinweis.

Weiss vielleicht auch jemand wie das Windows XP/2003/Vista/2008 machen?

Tim schrieb:

Siehe auch man: malloc unter "Bugs"

Das erklärt dann wohl, wieso mein Notebook beinahe gestorben ist

Shade Of Mine

hustbaer schrieb:

Weiss vielleicht auch jemand wie das Windows XP/2003/Vista/2008 machen?

http://msdn.microsoft.com/en-us/library/aa366887.aspx