• Bereits seit dem Intel 80386-Prozessor ist es möglich, logische Adreßräume zu erzeugen. Das heißt, daß der physikalische Speicher und der Adreßraum (4 GByte) in Pages von 4 KByte Größe aufgeteilt werden. Wird auf eine bestimmte Adresse bzw. Page zugegriffen (im Adreßraum), sucht der Prozessor über die sogenannte Pagetable die passende physikalische Page dazu und liefert die Daten von dort.

Findet er die Page nicht, fragt er das Betriebssystem, das ergibt manchmal die berühmte "Allgemeine Schutzverletzung" unter Windows.

Es ist damit möglich, mal eben locker festzulegen, daß z. B. das erste GByte des Adreßraums für das Programm und das zweite GByte für den Stack verwendet werden soll. Nur wo tatsächlich Speicher gebraucht wird, ist auch welcher vorhanden.

Andere Prozessoren können das höchstwahrscheinlich auch. --MichaelButscher

Für manche Anwendungen ist es sinnvoll, mit der Fehlersituation "zu wenig Speicher" so umzugehen, dass das Programm danach weiterarbeiten kann, für andere nicht. Die Behandlung von fehlgeschlagenen malloc()-Versuchen ist mühsam, aber nicht schwierig. Die Behandlung eines Stack-Überlaufs ist nichts, was auf portable Weise behandelt werden kann, wenn es überhaupt behandelt werden kann -- kw

• Richtig. Ich wollte nur erklären, daß man bei heutigen CPUs/Betriebssystemen? darauf nicht so sehr achten muß und schon mal ein paar Gigabyte als maximale Größe definieren kann.

Rein theoretisch betrachtet ist natürlich trotzdem ein Stacküberlauf möglich und dann auch nicht portabel zu behandeln. --mb

Wie gehen deine Programm damit um, wenn sie nicht die einzigen sind, die zu einem bestimmten Zeitpunkt laufen?

• Worin besteht da der Unterschied zwischen Speicherallokation auf dem "Stack" bzw. auf dem "Heap"? -- KurtWatzka
• Wird der Stack verwendet, so muß er so dimensioniert sein, daß er die größte denkbare Datenmenge eines Programms fassen kann. Bei einer Speicherallokation ueber den Heap dagegen muß das Programm nur soviel Speicher reservieren, wie es in der aktuellen Phase benötigt. Laufen mehrere stackorientierte Programme parallel, so wird der unnötig reservierte Speicherbereich um ein mehrfaches größer. Es gibt zwar Betriebssysteme, bei denen man die Größe des Stacks beim Programmaufruf angeben kann, aber in der Intelwelt fällt mir im Moment keines ein. Auch lasse ich zur Zeit Programme, die sich einen Speicherbereich teilen, bei meinen Betrachtungen außen vor, da das, so weit ich das sehe, bei stackorientierten Programmen sowieso nur schwer möglich ist.
• Das unterstellt, dass LazyAllocation?-Methoden für den Stack nicht möglich sind. Diese Annahme ist nicht auf allen Systemen erfüllt. -- kw

Wie übergibst du Speicherbereiche zurück an die rufende Funktion, wenn du die Bereiche ausschließlich auf dem lokalen Stack hast?

• Die aufrufende Funktion übergibt den Ausgabepuffer an die aufgerufene Funktion. Die aufrufende Funktion will das Objekt ja auch nach dem Aufruf weiterverwenden. Kein gutes Argument gegen Speicherallokation "auf dem Stack", will sagen mit der Speicherklasse auto -- KurtWatzka
• Wobei die rufende Funktion dummerweise bereits eine Annahme darüber machen muß, wie groß der von der gerufenen Funktion benötigte Puffer sein muß. Oder geht es in diesem Konzept nur um Optimierung der Zeit um jeden Preis? Ist mit auto etwas anderes als das Anlegen von Variablen auf dem lokalen Stack gemeint? --rae
• Für dynamische Speicheranforderungen ist das "Konzept" nicht gut geeignet. Mit auto ist die Speicherklasse mit diesem Namen in der Programmiersprache C gemeint. Ein Stack ist eine mögliche und sehr natürliche Implementation dieser Speicherklasse, aber nicht die einzig notwendige. Von der sehr prozessorspezifischen Sichtweise abgesehen, dass Allokation auf dem Stack schneller gehen soll, bleibt das Argument, dass Objekte, deren Lebensdauer an den Gültigkeitsbereich eines Bezeicheners gebunden ist, nicht vergessen werden können. Ob die Implementation über einen Stack realisiert ist, spielt dabei keine Rolle. Ja, die Entscheidung über die Größe des benötigten Puffers trifft bei diesem Konzept immer die aufrufende Funktion, aber mit einem VLA in C99 kann sie diese Entscheidung datenabhängig treffen -- kw