Array Größe vs Vector größe?

waschbaerFurcht

Hey vielen dank für die Antworten. Das ist mein Code zum testen:

long size;
 cout << numeric_limits<size_t>::max()/sizeof(int16_t) << endl;
 size = 1000000;
 int16_t *array;
 array = new (nothrow) int16_t[size];
 if(array!=0){
   for(int16_t i = 0; i < size; i++){
     array[i] = i;
   }
   cout << "last elemet: " << array[size-1] << endl;
   delete [] array;
 }

Segmentation fault in Zeile 8 sagt gdb. (Zeile 2 war nur ein Test...)

Ich nutze den mingw Compiler von Qt 4.7.3 (akuteller QtCreator) unter Windows XP. Den code von cooky451 probiere ich mal aus, aber da sehe ich kaum einen Unterschied oder?

@Belli:
Nur das Anlegen und Zerstören von dem Objekt geht bei mir auch. Das Problem tritt erst beim Zugriff auf. Wenn ich das Richtig verstehe, dann macht new keine Initialisierung, es sei denn man verwendet es mit einer Klasse, bei der wird dann der Konstruktor aufgerufen. (Bitte korrigiert mich wenn ich das falsch verstanden habe)

Ich habe irgendwo gelesen, dass man dem Combiler den die Heap Größe vorgeben muss die er Verwenden darf, stimmt das?

_matze

Wenn du genug Speicher am Stück frei hast, kannst du auch ein paar GB auf einmal anfordern, ist gar kein Problem. Zeig vielleicht mal mehr Code, bzw. bastel mal ein Minimalbeispiel zusammen, das den Fehler aufweist, und das wir ohne großen Aufwand kopieren und testen können.

Ich könnte glatt vermuten, dass du beim Zusammenbasteln dieses Beispiels den Fehler findest.

waschbaerFurcht

_matze schrieb:

Wenn du genug Speicher am Stück frei hast, kannst du auch ein paar GB auf einmal anfordern, ist gar kein Problem. Zeig vielleicht mal mehr Code, bzw. bastel mal ein Minimalbeispiel zusammen, das den Fehler aufweist, und das wir ohne großen Aufwand kopieren und testen können.

Ich könnte glatt vermuten, dass du beim Zusammenbasteln dieses Beispiels den Fehler findest.

Mehr als 2GB habe ich noch Frei, sagt Windows. Code -> Siehe mein letzter Post. Fehlt nur #include <iostrem>, using namespace std; und natürlich die Mainfunktion.

@cooky451: Der code schmiert bei mir auch ab.

Kann das ein Problem von Qt sein?

_matze

Deine Zählvariable i ist nur 16 Bit groß, da passt der Wert von size gar nicht rein. Mach da mal ein 32 Bit Integer draus.

EDIT: Das Problem ist hier, dass i irgendwann überläuft und negativ wird (ist ja signed). Daher versuchst du, an Stelle array[-32768] oder so zu schreiben, und das geht natürlich nicht.

waschbaerFurcht

Oh man, jetzt komm ich mir ech doof vor. Ja mit sowas wie int32_t i = 0 klappt's. Aber warum geht der code von cooky451 nicht?

EDIT Ich sollte mir angewöhnen immer uint und co für index-variabeln zu verwenden...

_matze

waschbaerFurcht schrieb:

Aber warum geht der code von cooky451 nicht?

Der geht. "schmiert ab" reicht nicht, was genau ist denn bei dir der Fehler mit dem Code? Und hast du ihn kopiert und ohne Änderung ausprobiert?

waschbaerFurcht

_matze schrieb:

waschbaerFurcht schrieb:

Aber warum geht der code von cooky451 nicht?

Der geht. "schmiert ab" reicht nicht, was genau ist denn bei dir der Fehler mit dem Code? Und hast du ihn kopiert und ohne Änderung ausprobiert?

Naja, ich habe ihn schon ausprobiert. Sieht bei mir dann so aus:

//using namespace std;
char *buf = new(nothrow) char[20971520];
if (!buf)
  cout << "fail"; 
  return -1;
int i;
cin >> i;
cin >> buf[i];
cout << buf[i] << endl;
delete[] buf;

EDIT (Der using namespace seht bei mir schon irgendwo...)

"Schmiert ab" heißt in dem Zusammenhang, dass return -1 angesprungen wird, weil !buf == true ist. Demnach wurde buf nicht richtig initialisiert. (warum auch immer)

asc

waschbaerFurcht schrieb:

"Schmiert ab" heißt in dem Zusammenhang, dass return -1 angesprungen wird, weil !buf == true ist. Demnach wurde buf nicht richtig initialisiert. (warum auch immer)

Nein, bei dem Code wird immer -1 zurückgegeben, wegen fehlender Klammersetzung.

cooky451

Sorry, in meinem Code war da nur ein Komma zwischen, was zugegeben etwas schlecht "gehackt" ist. Das funktioniert mit return aber nicht, das exit() war schon Absicht

waschbaerFurcht

asc schrieb:

waschbaerFurcht schrieb:

"Schmiert ab" heißt in dem Zusammenhang, dass return -1 angesprungen wird, weil !buf == true ist. Demnach wurde buf nicht richtig initialisiert. (warum auch immer)

Nein, bei dem Code wird immer -1 zurückgegeben, wegen fehlender Klammersetzung.

Oh man. Ich geht jetzt glaube ich ins Bett... Kopf->Wand.
Vielen Dank für eure Geduld mit mir. Kann man den Thread irgendwie schließen?

_matze

Ich wusste schon, warum ich dich gefragt habe, ob du den Code ohne Änderungen ausprobiert hast.

_matze

waschbaerFurcht schrieb:

Kann man den Thread irgendwie schließen?

Kannst du nicht und brauchst du auch nicht, passt schon. Gute Nacht!

waschbaerFurcht

Kann nichts mehr dazu sagen... Versinke gerade im Boden...

pumuckl

waschbaerFurcht schrieb:

"Schmiert ab" heißt in dem Zusammenhang, dass return -1 angesprungen wird, weil !buf == true ist. Demnach wurde buf nicht richtig initialisiert. (warum auch immer)

So. Du hast also nicht nur gesehen, dass -1 ausgegeben wurde, sondern auch dass !buf==true ? Ich bezweifle das mal stark. Ich korrigiere deinen Satz mal so, wie du ih hättest schreiben müssen:
""Schmiert ab" heißt in dem Zusammenhang, dass return -1 angesprungen wird, ohne es genau zu wissen rate/schätze/vermute ich mal, weil !buf == true ist. Demnach wurde buf nicht richtig initialisiert , wenn ich richtig geraten habe. (warum auch immer)"

waschbaerFurcht schrieb:

Naja, ich habe ihn schon ausprobiert.

Ausprobiert triffts. Debuggen wäre besser gewesen, dann hättest du nämlich gesehen, dass !buf durchaus nicht true war und return -1 trotzdem angesprungen wurde. Von da bis zum Erkennen des Klammerfehlers wäre es nur ein kleiner Schritt gewesen.

Was lernen wir daraus? Nicht raten, sondern Werte im Debugger anschauen

_matze

waschbaerFurcht schrieb:

Kann nichts mehr dazu sagen... Versinke gerade im Boden...

Brauchst du nicht, das sind die typischen, kleinen Fehlerchen, die wohl jedem schon mal passiert sind. Mir soll keiner erzählen, dass er noch nicht Klammern vergessen oder falsch gesetzt hat. Zumal du ja nur Code falsch geändert hast. Das ist übrigens einer der Gründe, warum ich auch einzeilige if's immer mit Klammern notiere (neben der Lesbarkeit).

CStoll

cooky451 schrieb:

Sorry, in meinem Code war da nur ein Komma zwischen, was zugegeben etwas schlecht "gehackt" ist. Das funktioniert mit return aber nicht, das exit() war schon Absicht

Ach, wenn man sich nur genug anstrengt, kriegt man auch Komma-Operator und return unter einen Hut

if (!buf)
  return cout << "fail", -1;

Ethon

Wenn du genug Speicher am Stück frei hast, kannst du auch ein paar GB auf einmal anfordern, ist gar kein Problem. Zeig vielleicht mal mehr Code, bzw. bastel mal ein Minimalbeispiel zusammen, das den Fehler aufweist, und das wir ohne großen Aufwand kopieren und testen können.

Es muss nicht mal ein zusammenhängender Block sein, das ist ja der Sinn von virtuellem Speicher, dass der physische Speicher fragmentiert oder sogar ausgelagert sein kann.

_matze

Ethon schrieb:

Wenn du genug Speicher am Stück frei hast, kannst du auch ein paar GB auf einmal anfordern, ist gar kein Problem. Zeig vielleicht mal mehr Code, bzw. bastel mal ein Minimalbeispiel zusammen, das den Fehler aufweist, und das wir ohne großen Aufwand kopieren und testen können.

Es muss nicht mal ein zusammenhängender Block sein, das ist ja der Sinn von virtuellem Speicher, dass der physische Speicher fragmentiert oder sogar ausgelagert sein kann.

Sicher, dass das auch für Allokationen mit new/malloc gilt? Ich meine, mal was gelesen zu haben, dass die einen zusammenhängenden Speicher im physisch vorhandenen Speicher brauchen, unabhängig davon, ob der Bereich später mal ausgelagert wird. Bin mir aber nicht wirklich sicher.

Ethon

_matze schrieb:

Ethon schrieb:

Wenn du genug Speicher am Stück frei hast, kannst du auch ein paar GB auf einmal anfordern, ist gar kein Problem. Zeig vielleicht mal mehr Code, bzw. bastel mal ein Minimalbeispiel zusammen, das den Fehler aufweist, und das wir ohne großen Aufwand kopieren und testen können.

Es muss nicht mal ein zusammenhängender Block sein, das ist ja der Sinn von virtuellem Speicher, dass der physische Speicher fragmentiert oder sogar ausgelagert sein kann.

Sicher, dass das auch für Allokationen mit new/malloc gilt? Ich meine, mal was gelesen zu haben, dass die einen zusammenhängenden Speicher im physisch vorhandenen Speicher brauchen, unabhängig davon, ob der Bereich später mal ausgelagert wird. Bin mir aber nicht wirklich sicher.

new/malloc setzen ja auf dem virtuellen Speicher auf, von daher brauchen die auf jeden Fall einen zusammenhängenden virtuellen Speicherblock. Ob der physisch zusammenhängt,können sie ja nicht wissen und es ist nicht relevant.
Wenn das OS keinen so großen Block rausrückt ist natürlich Sense.