static variablen; Heap oder Stack?



  • Ok,

    ganz einfache Frage:
    wo werden static variablen angelegt, Heap oder stack?

    Lasst mich raten: Stack, da ständige verfügbarkeit gewährleistet werden muss.



  • Nö, im globalen Speicherpool. Der Stack ist eher für temporäre auto Variablen.



  • Ok, hätte den 50:50 Joker nehmen sollen.

    Was wird denn sonst noch so auf dm Heap erzeugt?
    - dynamischer Speicher (mit malloc/new bzw. delete/free)
    - static variablen

    was noch?



  • JDHawkins schrieb:

    wo werden static variablen angelegt, Heap oder stack?

    Weder noch.



  • static variablen landen normalerweise im Datensegment deiner Anwendung



  • Hallo Dracula,

    im Datensegment?
    Liegt das daran dass sie implizit initialisiert werden, damit einen Wert haben und deshalb im Datensegment liegen?



  • JDHawkins schrieb:

    im Datensegment?
    Liegt das daran dass sie implizit initialisiert werden, damit einen Wert haben und deshalb im Datensegment liegen?

    die müssen ihren wert behalten. deshalb müssen die irgendwo untergebracht werden, wo sie leicht erreichbar sind. das könnte auch auf'm heap sein. der startup-code könnte z.b. vorm aufruf von 'main' und bevor er globale und statische variablen initialisiert, einmal 'malloc' aufrufen, um sich ein datensegment zu beschaffen.
    🙂



  • @frikey: ich versteh den satz nicht mist



  • das könnte auch auf'm heap sein. der startup-code könnte z.b. vorm aufruf von 'main' und bevor er globale und statische variablen initialisiert, einmal 'malloc' aufrufen, um sich ein datensegment zu beschaffen.

    Ich denke das ist falsch!
    Eine Exe entält informationen über die Segmente aus denen sie besteht, die wichtigsten sind:
    Code Segment, das ist der Prgrammcode (asm: .code) - steht natürlich in der Exe.
    Const Segment, enthält unveränderlihce Daten (asm: .const), alle string literale stecken zum Besipiel hier drin - steht natürlich auch in der Exe.
    Daten segment, enthält initalisierte Daten (asm: .data), zB wenn du irgendwo eine statische Variable mit static int i = 345; declarierst - steht natürlich auch in der Exe.
    Uniinitialisierte Daten Segment (asm: .data?), hier drin landen alle uninitialiserten Statischen variablen - steckt nicht in der Exe
    Stack segment, enthält den Stack - steckt nicht in der Exe

    Die ausführbare Datei enthält informationen zu diesen ganzen segmente, wie zum Beispeil die Größe.
    Da es innlos ist, den Stack und das uninitialisierte Daten in das image (die exe datei) zu packen, bleibt das weg.

    Bei Start der Anwendung sorgt das Betriebssystem dafür, dass ein genügend großer Bereich im Speicher gefunden wird, in den die segmente der Exe abgelegt werden, jetzt natürlich mit den beiden fehlenden Segmente.
    Den Speicher holt definitiv nicht der CRT-Code, der selbst erst die main called.

    Ich lass mich da gern korrigieren, aber so hab ich das mal verstanden.



  • vlad_tepesch schrieb:

    das könnte auch auf'm heap sein. der startup-code könnte z.b. vorm aufruf von 'main' und bevor er globale und statische variablen initialisiert, einmal 'malloc' aufrufen, um sich ein datensegment zu beschaffen.

    Ich denke das ist falsch!
    Eine Exe entält informationen über die Segmente aus denen sie besteht...

    ja, das steht da drin. aber C schreibt nicht vor, woher der speicher kommt oder ob es oberhaupt sowas wie stack und heap gibt, sondern nur wie sich alles verhalten soll. also z.b. dass statische und globale variablen vorm ersten zugriff initilisiert sind (mit 0, wenn nichts anderes im code steht), dass lokale veriablen ihre gültigkeit verlieren, wenn der {}-block verlassen wird usw. C schreibt auch die interne funktionsweise von malloc/free nicht vor. also theoretisch könnte es so ablaufen:

    void *static_variablen = malloc(...);
    void anderes_segment = malloc(...);
    ... = malloc (...);
    ...
    memcpy (static_variablen, initialisierungsdaten);
    int res = main(...)
    free (static_variablen);
    free (anderes_segment);
    free (...);
    ...
    return_to_shell(res);
    

    ^^dass in wirklichkeit nicht malloc/free sondern irgendwas os-spezifischen verwendet wird, will ich ja nicht abstreiten, aber so würde es auch gehen.
    🙂


Anmelden zum Antworten