Frage zu malloc()
-
vcxvc schrieb:
welche systeme wären das zum beispiel?
ich denke uCLinux z.b, das hat ja kein virtuelles speichermanagement und auch kein brk/sbrk usw. malloc/realloc greifen speicher vom globalen pool ab. vergisst ein prozess, den speicher wieder freizugeben, ist er futsch.
-
vcxvc schrieb:
welche systeme wären das zum beispiel?
Embedded Controller z.B.
Wenn nicht gerade zwingende Gründe dagegen sprechen (die gibt's fallweise auch), sollte jedes malloc() sein free() bekommen, das hält den Code kompatibel, ob nun ein OS mit Kontextüberwachung drüber sitzt oder nicht.PS: Was für'ne blöde Idee, ohne realloc auszukommen. Ist ja so, wie geh' zum 100m- Sprint, hack' Dir aber vorher ein Bein ab. Eine passende Prothese wäre übrigens memcpy()
-
Barbarossa schrieb:
Aber im Beispielcode des Buches wurde doch eine do while Schleife implementiert, und so lang der nutzer nicht 0 eingibt, kann er immer wieder Heap allozieren??? Und dabei wird ja jedes Mal der frühere, zu klein, reservierte Bereich nicht mehr freigegeben...
Ich habe nicht weitergelesen und mir nur das erste Beispiel angesehen. Ja, im letzten Beispiel fehlt ein free.
Du kannst auch davon ausgehen, dass dein Taschenrechner keinen Heap hat und malloc wohl eher nicht benutzt werden würde.
-
nwp2 schrieb:
Du kannst auch davon ausgehen, dass dein Taschenrechner keinen Heap hat und malloc wohl eher nicht benutzt werden würde.
-
Ich will so einen haben.
-
pointercrash() schrieb:
PS: Was für'ne blöde Idee, ohne realloc auszukommen. Ist ja so, wie geh' zum 100m- Sprint, hack' Dir aber vorher ein Bein ab. Eine passende Prothese wäre übrigens memcpy()
Ich weiss nicht in wie weit es richtig ist, aber da realloc immer als langsam angepriesen wird ist diese Funktion für mich auch ein gebranntes Kind
.
-
player4245 schrieb:
Ich weiss nicht in wie weit es richtig ist, aber da realloc immer als langsam angepriesen wird ist diese Funktion für mich auch ein gebranntes Kind
.Höre ich jetzt gerade zum ersten mal.
-
hab gerade mal gsucht und nirgends was gefunden. Ich bin mir aber sicher das mal irgendwo gelesen zu haben.
-
player4245 schrieb:
Ich weiss nicht in wie weit es richtig ist, aber da realloc immer als langsam angepriesen wird ist diese Funktion für mich auch ein gebranntes Kind
naja, realloc/malloc/free usw. sind generell langsam, jedenfalls viel langsamer beim allozieren als z.b. GC-heaps (wie in Java und C# z.b.) und natürlich viel-viel langsamer als feste arrays (hallo nwp2 *fg*). realloc's worst-case ist, wenn der bestehende speicherblock nicht erweitert werden kann. dann wird ein neuer angelegt, alles rüberkopiert und der alte freigegeben.
-
player4245 schrieb:
Ich weiss nicht in wie weit es richtig ist, aber da realloc immer als langsam angepriesen wird ist diese Funktion für mich auch ein gebranntes Kind
.Kommt drauf an, wie man realloc einsetzt. Nimmt man es z.B. für ein Zeigerarray, das die Zeiger von irgendwelchen Elementen ( z.B. Strukturen ) speichert, indem es bei jedem neu hinzugekommen Element um eins allokiert, dann ist es gegenüber einer verketteten Liste nicht nur langsam, sondern nur langsam.
:p
Dann ist es schon besser, wenn man ganze Blöcke von Zeigern mit NULL vorbelegt. Das Allokieren findet dann nicht mehr so oft statt, sondern nur dann, wenn ein Block aufgebraucht ist.