Dynamisches Array
-
Sone schrieb:
Ramanujan schrieb:
Dieser Wert könnte aber (rein theoretisch) variabel sein. Allerdings kann man dann nicht beim Betreten einer Funktion wissen, um wie viel der Stack vergrößert wird.
Soso, der Stack kann also vergrößert werden? Dann brauchen wir in C ja kein
mallocmehr,allocatuts schon
Nein. An der Aussage von Ramanujan ist nichtmal was falsch. In der Tat kann der Stack vergrößert werden und das Betriebssystem arbeitet auch genau so. Zwar gibt man am Anfang an, wie groß der Stack maximal werden wird, das Betriebssystem alloziert trotzdem erst Stück für Stück die benötigten pages. Und natürlich gibt es noch weitere Unterschiede zwischen alloca und malloc, zum Beispiel weil alloca nur den aktuellen stackframe ändern kann und weil der Stack prinzipbedingt einige weitere Einschränkungen hat - zum beispiel das auf dem stack allozierter Speicher nicht länger existieren kann, als der Stackframe in dem er sich befindet.
//edit die Implementation von alloca und VLAs ist nicht einmal sonderlich komplex. Man muss den Stackframe anders aufbauen und zusätzlichen Aufräumcode erzeugen, aber das ist alles keine Magie. (ich kann allerdings nicht mehr beschreiben wie genau das ging, Sprachimplementierung ist ewig her, war aber einfach genug um vom Prinzip auf 2 Tafeln zu passen)
-
otze schrieb:
Sone schrieb:
Ramanujan schrieb:
Dieser Wert könnte aber (rein theoretisch) variabel sein. Allerdings kann man dann nicht beim Betreten einer Funktion wissen, um wie viel der Stack vergrößert wird.
Soso, der Stack kann also vergrößert werden? Dann brauchen wir in C ja kein
mallocmehr,allocatuts schonNein. An der Aussage von Ramanujan ist nichtmal was falsch. In der Tat kann der Stack vergrößert werden und das Betriebssystem arbeitet auch genau so. Zwar gibt man am Anfang an, wie groß der Stack maximal werden wird, das Betriebssystem alloziert trotzdem erst Stück für Stück die benötigten pages. Und natürlich gibt es noch weitere Unterschiede zwischen alloca und malloc, zum Beispiel weil alloca nur den aktuellen stackframe ändern kann und weil der Stack prinzipbedingt einige weitere Einschränkungen hat - zum beispiel das auf dem stack allozierter Speicher nicht länger existieren kann, als der Stackframe in dem er sich befindet.
o.O
Gut, da hab ich wohl viel zu tief gegriffen. Dachte, der Stack ist von vornherein so groß wie er immer ist (ca. 1 - 10 MB), aber anscheinend wäre das ja bei näherem überlegen auch reichlich bescheuert...?Edit: Doch das "(rein theoretisch)" kann er weglassen.
-
Ja, da ist auch etwas Magie dahinter, die auf den virtuellen Addresslisten der CPU basiert.
Das Programm selbst allokiert niemals Speicher für den Stack. Stattdessen wird ausgenutzt, dass die CPU eine Hardware-Exception schmeißt, wenn auf eine virtuelle Addresse zugegriffen wird, die nicht vergeben ist. Das Betriebssystem überprüft dann, ob die Addresse im Stackbereich liegt und wenn dies der Fall ist, wird eine weitere Page allokiert und auf der CPU dieser virtuelle Speicherbereich freigeschaltet.
Im Kontext dieses Threads meinte Ramanujan aber nur den Stackpointer, bzw den aktuellen Stackframe, der kann natürlich beliebig vergrößert werden, weil der Frame nur eine Datenstruktur ist, die das Programm bei Eintritt in zum Beispiel eine Funktion automatisch erzeugt. Und dort irgendwo einen Wert zu überschreiben und den Stackpointe rzu erhöhen ist kein Problem.
-
otze schrieb:
Im Kontext dieses Threads meinte Ramanujan aber nur den Stackpointer
Ja, genau. Meine Formulierung war leider etwas unpräzise.