Diese Seite ist unverschlüsselt! Um sicherzustellen, das Ihr Passwort nicht ausgelesen werden kann, sollten Sie auf die verschlüsselte Seite wechseln!

    Herzlich Willkommen, lieber Gast!
  Sie befinden sich hier:

  Forum » C / C++ (ANSI-Standard) » Probleme mit Arrays (Zeiger)
Forum | Hilfe | Team | Links | Impressum | > Suche < | Mitglieder | Registrieren | Einloggen
  Quicklinks: MSDN-Online || STL || clib Reference Grundlagen || Literatur || E-Books || Zubehör || > F.A.Q. < || Downloads   

Autor Thread - Seiten: [ 1 ] > 2 <
010
10.06.2005, 23:49 Uhr
Lensflare



 @ ~CDW:

Zitat:
wegen dem free(buffer) - denn das ist "zuviel" (Du hast ja kein malloc für diesen free).

meinst du vielleicht free(intArray) ?

das habe ich nämlich zwei mal drin, free(buffer) aber nur einma, und davor hab ich dem buffer speicher reserviert.

ich weiss, das beispiel ist verwirrend. das kommt daher, dass ich ganz wild und durcheinander experimentiert und mit copy+paste herumgeschoben habe und dann habe ich alles überflüssige herausgelöscht und es ist dieses fragment übriggeblieben, das dieses komische verhalten zeigt.
--
Wenn das Gehirn so einfach wäre, dass wir es verstehen könnten, wären wir so einfach, dass wir es nicht verstehen könnten.
(Emerson Pugh Trost)
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
011
10.06.2005, 23:50 Uhr
FloSoft
Medialer Over-Flow
(Administrator)


dann alloziert dir win "hinten dran" speicher für alles was größer als 4 bytes ist, alles was drunterliegt, landet in den lücken. Wäre ja noch schöner wenn win deine zeiger einfach verändert
--
class God : public ChuckNorris { };
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
012
11.06.2005, 00:03 Uhr
Lensflare
Zitat:

dann alloziert dir win "hinten dran" speicher für alles was größer als 4 bytes ist, alles was drunterliegt, landet in den lücken. Wäre ja noch schöner wenn win deine zeiger einfach verändert


hmmm...
heisst das, wenn ich ein grosses programm habe, das nur 4 byte arrays benutzt, kann es dazu kommen, dass ich nicht genug speicher habe um für ein weiteres array speicherplatz zu reservieren, das grösser ist als 4 bytes?
Obwohl ich theoretisch aber noch die hälfte an speicherplatz in form von Lücken haben kann.

kommt mir vor wie eine extreme platzverschwendung
ich stell mir eine lange sitzbank mit peronen vor, die in regelmäßigen abständen sitzen. und keiner will ein wenig rutschen, um einer breiteren person einen sitzplatz zu gewähren.
--
Wenn das Gehirn so einfach wäre, dass wir es verstehen könnten, wären wir so einfach, dass wir es nicht verstehen könnten.
(Emerson Pugh Trost)
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
013
11.06.2005, 00:11 Uhr
~CDW
Gast


gute frage, habe deshalb so was mit lcc32 compiliert:

C++:
int main(int argc, char *argv[])
{
char *array1 = (char*)malloc(4);
  char *array2 = (char*)malloc(4);
  char *array3 = (char*)malloc(4);
  char *array4 = (char*)malloc(4);
  free(array2);
  free(array4);
  array2 = (char*)malloc(18);
  return 0;

}

und mit Olly betrachtet: erstens verwendet lcc die WindowsAPI malloc. Diese liefert zeiger auf den Speicher der sogar freundlicherweise initialisiert wurde (mit FF EE). Im debugger kann man schön sehen wie Windows mindesten 32 Byte Speicher zuteilt (egal ob malloc(1) oder malloc(8)
da wird noch zusätzlich irgendeine Verwaltunsinfo dazugehängt (habe nicht auf diese geachtet).. Wenn man jetzt nach den frees ein malloc(5) macht dann wird wieder "der freigegebene" Speicher zwischen den Array benutzt (weil ja eben 32byte blöcke sind). Wird aber malloc(gößere Menge) aufgerufen wird einfach "weiter hinten" drangehängt - so dass ziemlich viele Lücken übrig bleiben. Das ist natürlich unschön aber man kann es von der anderen Seite betrachten: heutzutage hat man "genug" speicher und die paar Bytes fallen nicht ins gewicht. Außerdem macht man für gewöhnlich in seinen anwendungen entweder keine "exzessiven" mallocs oder zumindest in einheitlicher Größe. Würde malloc hier alles schön verwalten und zusammenschieben hätte das beträchtliche Perfomanceeinbußen. Außerdem können die Adressen im nachhinein nicht mehr umgebogen werden da es ja "direkte" Zeiger sind. so hat malloc keinen einflüss mehr weil Du es ja eben in den Variablen speicherst.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
014
11.06.2005, 00:16 Uhr
~CDW
Gast


grr - ihr seid zu schnell für mich

Zitat:
meinst du vielleicht free(intArray) ?

ist eigentlich wursch welches davon genau, aber ich hab free(buffer) genommen weil dafür kein malloc "gemacht" wurde . Wenn man nämlich einen "free" wegmacht dann funktioniert das Programm wie es soll. *schnell post abschick bevor sich wieder was ändert*
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
015
11.06.2005, 00:26 Uhr
Lensflare



 nun, ich denke malloc könnte schon "einfluss" auf die zeiger haben, indem es vielleicht von jedem zurückgegebenen zeiger eine referenz speichert oder so...

aber es stimmt schon, die ganze herumschieberei der daten würde bestimmt zu großen performanceverlusten führen...

genau das wird doch mit der festplatte bei der defragmentierung gemacht oder? und mit meiner 4 GB festplatte hab ich damals 8 stunden oder so gebraucht (ich weiss, der RAM ist viel schneller als die Festplatte )...
ich will nicht wissen, wie lange es jetzt bei meiner 160 GB platte dauern würde
--
Wenn das Gehirn so einfach wäre, dass wir es verstehen könnten, wären wir so einfach, dass wir es nicht verstehen könnten.
(Emerson Pugh Trost)
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
016
11.06.2005, 00:52 Uhr
~CDW
Gast



Zitat:
nun, ich denke malloc könnte schon "einfluss" auf die zeiger haben, indem es vielleicht von jedem zurückgegebenen zeiger eine referenz speichert oder so...

naja, eine Referenz braucht man schon um den Speicher wieder frei zu geben (also eine art tabelle "adresse xyz, 4 Bytes belegt") oder neuen dazu zu reservieren - so dass die Funktion "sieht" ab welcher Adresse Speicher frei ist und vergeben werden kann. Aber mit dem "Einflüss" meine ich eher dass wenn malloc etwas ändern sollte man in seinem Programm dann mit "wilden" Pointern schießt. Denn malloc ist nicht in der Lage die Zeiger in deinem Programm auch noch zu ändern.
um nochmal auf die Frage einzugehen:

Zitat:
das nur 4 byte arrays benutzt, kann es dazu kommen, dass ich nicht genug speicher habe um für ein weiteres array speicherplatz zu reservieren, das grösser ist als 4 bytes?

Wenn Du die ganze Zeit nur 4 Bytes allozierst und wieder freigibst ist es kein Problem da die Lücken genutzt werden. Um sowas zu erreichen müsstest du schon "mischen" (bei windows' malloc auch mehr als 32 Byte benutzen). Ich weiß aber nicht auf Anhieb wieviel Heap (welches malloc standarmäßig benutz) unter Win zur verfügung steht (ich glaube 1 MB, kann natürlich vergrößert werden) kann also schon ziemlich schnell knapp werden.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
017
11.06.2005, 01:21 Uhr
Lensflare
Zitat:
Wenn Du die ganze Zeit nur 4 Bytes allozierst und wieder freigibst ist es kein Problem da die Lücken genutzt werden.

ich hab mir schon gedacht, dass das kommt, aber:
es wäre auch möglich, dass ich sie erst alle alloziere und dann die hälfte freigebe.
die lücken würden sich also nicht füllen
--
Wenn das Gehirn so einfach wäre, dass wir es verstehen könnten, wären wir so einfach, dass wir es nicht verstehen könnten.
(Emerson Pugh Trost)
Dieser Post wurde am 11.06.2005 um 01:22 Uhr von Lensflare editiert.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
018
11.06.2005, 10:54 Uhr
Spacelord
Hoffnungsloser Fall


@CDW:
Heap hat man soviel zu Verfügung wie der virtuelle Adressraum hergibt .Der Stack eines Threads hat unter Win die "Standard-Startgröße" von 1MB.

@all:
Was den Einfluss von malloc auf die Fragmentierung angeht.Bei der ganzen Geschichte darf man nicht vergessen dass diese ganzen "Speicherlücken" ohnehin nur im virtuellen Adressraum deiner Anwendung bestehen.Darauf wie die theoretischen Adressbereiche deiner Anwendung auf den realen physischen Speicher(RAM/Auslagerungsdatei) abgebildet werden hat Windows durchaus Einfluss.Wie aber schon erwähnt wurde sind diese "Defragmentierungen" extrem rechenintensiv.Der reale Speicher wird Seitenweise verwaltet.Unter Windows normalerweise 4096 Byte pro Seite.Da kommen also insgesamt schon einige Seiten zusammen die es zu verwalten gibt.
Wenn man jedesmal die komplette Seitentabelle aktualisieren möchte um in der einen oder anderen Seite nen 4Byte Loch(dass ja nicht verloren ist!) zu stopfen dürfte das Betriebssystem wohl für nichts anderes mehr Zeit finden.

@Lensflare:

Zitat von Lensflare:

es wäre auch möglich, dass ich sie erst alle alloziere und dann die hälfte freigebe.
die lücken würden sich also nicht füllen



Wenn du irgendwo 4Byte unterbringen möchtest und das OS findet ne 4 Byte Lücke dann nimmt es die auch.Warum sollte es das nicht tun?
Abgesehen davon wird new,malloc und das ganze Gelumpe irgendwann in den Tiefen der Win C-Library mit VirtualAlloc etc umgesetzt.
Also wenn du nen Programm schreibst dass den Speicher dermassen durchlöchert,hast du durchaus die Möglichkeit dir nen eigenen Heap zu besorgen und diesen zu verwalten wie du dir das denkst.
In Jeffrey Richters "Windowsprogrammierung für Experten" wird recht ausführlich auf das Speichermangement von Windows und die Möglichkeiten die dir die WinApi auf nem niedrigen Level bietet eingegeangen.
Damit ist dann natürlich jegliche Plattformunabhängigkeit futsch.....

MfG Spacelord
--
.....Ich mach jetzt nämlich mein Jodeldiplom.Dann hab ich endlich was Eigenes.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
019
11.06.2005, 21:38 Uhr
~CDW
Gast



Zitat:
@CDW:
Heap hat man soviel zu Verfügung wie der virtuelle Adressraum hergibt .Der Stack eines Threads hat unter Win die "Standard-Startgröße" von 1MB.

naja, ansichtsache denn je nach Windows stehen für das Programm nur bis 2 GB (bzw auf Advanced/Dateserverversionen bis 3 GB) zur verfügung, der Rest des Adressraumes ist für Systemprozesse reserviert. Gemeint sind hier natürlich nur die Winversionen die nicht mehr als 4GB Speicher adressieren können .
Also auf einem "normalen" win2k/XP 2 GB. Davon muss man nochmal den Adresspace der Applikation abzwacken (also wo der ausführbare Code hingemappt wird). Dann je nach dem wieviele Thread man nutzt und wieviele DLLs das Programm lädt, kommt noch ein Batzen ab (denn die DLLs werden auch in den Speicher gemappt - egal ob sie nur bei bedarf oder direkt geladen werden). Jetzt kommt noch der Stack dazu. Also bleibt für den Heap nicht mehr "viel" übrig. Gemeint war natürlich der "Heap" der von windows zur verfügung gestellt wird - der fängt irgendwo bei 14xxxxxx an (win XP) und wächst nach unten. Standarmäßig 1MB wird aber automatisch erweitert (hab jetzt die Seite wiedergefunden:http://www.suvi.org/theory/InsideWindowsNT.html). Der Stack fängt bei (meinem XP) bei 12FFFC an und wächst nach oben (nicht ganz an die 0 - wegen dem nullpointern). Kann also nicht bei Bedarf erweitert werden und muss schon vorher festgelegt werden. Aber wie schon erwähnt - alles Ansichtssache solange man keine super-Anwendungen schreibt die sehr viel Speicher brauchen, diesen sehr defragmentieren und dazu noch rechenintensiv sind muss man sich darum keine Gedanken machen.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
Seiten: [ 1 ] > 2 <     [ C / C++ (ANSI-Standard) ]  


ThWBoard 2.73 FloSoft-Edition
© by Paul Baecher & Felix Gonschorek (www.thwboard.de)

Anpassungen des Forums
© by Flo-Soft (www.flo-soft.de)

Sie sind Besucher: