Franz_grundi:
Aber warum belegt das eine sooo viel mehr Speicher, als das andere.
Das scheint nur so.
Franz_grundi:
... funktion ...
... Global ...
In Funktionen werden Variablen lokal zur Laufzeit angelegt, das sieht der Compiler noch nicht. Globale Variablen sieht der Compiler, weshalb diese in die Speicherberechnung mit eingehen.
Du könntest den freien Speicher zur Laufzeit überprüfen:
// Quelle: http://jeelabs.org/2011/05/22/atmega-memory-use/
int freeRam () {
extern int __heap_start, *__brkval;
int v;
return (int) &v - (__brkval == 0 ? (int) &__heap_start : (int) __brkval);
}
was würde dann der Zeiger bei meinem Bsp bedeuten ?
char* Text [2] = {"Hier dann Text"};
Dachte ich rufe dann irgendwo auf : println(Text[1]); und der Zeiger zeigt auf das Gesamte was im Array an Position 1 steht, also den Gesamten Text? Ist dem nicht so ?
Und dass heisst :
const char* Text = "Hier dann Text";
dass immer wenn Text aufgerufen wird, bsp println(Text); wird mit dem Zeiger der Gesamte Bereich angezeigt? Und ohne * würde er nur einen Buchstaben anzeigen?
Hey agmue, danke für die Erklärung und den Beispielcode, probier ich mal
Lerne den Zusammenhang zwischen Arrays und Zeiger. Array-Variablen entsprechen Zeigern auf das erste Element. Deshalb sind C Strings Arrays und Arrays aus Strings sind Arrays aus Zeigern
char* Text [2] = {"Hier dann Text"};
Das ist ein Array aus Strings, bei denen nur einer definiert ist
combie:
Aber nicht die lokalen variablen, denn die landen auf dem Stack.
Und dieser geht in deine Rechnung nicht mit ein.
Doch.
Wenn du dir das freemem - Beispiel anguckst, berechnet das den Platz zwischen einer gerade eben angelegten lokalen Variablen und dem Heap. Dieser Platz ist zum Zeitpunkt des Aufrufs frei, entweder für weitere Lokale Variable / Rücksprungadressen auf dem Stack oder für dynamischen Speicher auf dem Heap.
Das Problem der freeRam-Funktion ist, dass sie nur eine Momentaufnahme zum Aufrufzeitpunkt liefert. Das heißt nicht, dass der freie Speicher zu einem anderen Zeitpunkt nicht deutlich kleiner sein kann. Man müsste die Funktion dann aufrufen, wenn der Stack seine größte Ausdehnung hat. Aber das ist nicht so einfach rauszubekommen, es könnte auch ja auch durchaus innerhalb einer Lib sein.
Doch.
Wenn du dir das freemem - Beispiel anguckst, berechnet das den Platz zwischen einer gerade eben angelegten lokalen Variablen und dem Heap.
Auch das hilft dir nicht wirklich beim abschätzen des freien Speichers
Denn:
Momentaufnahme zum Aufrufzeitpunkt
Besser ist es (evtl.), bevor main() los läuft, den ganzen Speicher mit z.B. 0xaa voll zu schreiben, und nach druch spielen aller Funktionalität, nachzuschauen, wieviel 0xaa noch da sind.
In der Hoffnung, dass die Daten keine 0xaa enthalten.
Irgendwo, in meiner Wühlkiste sollte ich das haben, müsste das nur rausoperieren.
Du siehst damit die irgendwann mal belgten Bereiche. Richtig.
Du siehst aber nicht den Zeitbezug.
Annahme: Ich brauche am Anfang kurzzeitig viel Heap für irgendwas und gebe den vollständig wieder frei.
Danach kann ich so viel Abstand zwischen Heap und Stack frei haben, dass das für einen problemlosen Betrieb vollkommen ausreicht.
Es ist also ein Worst-Case-Darstellung, die auch nicht alle Fälle betrachtet.
Ich denke, beide Varianten sind in ihrer Kombination sinnvoll. Das 0xAA für den Worst-Case-Fall und der Aufruf von freeRam an kritischen Stellen, um den Verlauf dort zu erfassen.
Ansonsten gilt immer noch der alte Spruch: Wer misst, misst Mist.