[C++] Was passiert mit globalen Variablen nach Programmausführung?

Probiere es doch einfach aus.
Schreibe ein Programm, mit einer sehr großen globalen Variable und führe 
es mehrfach aus. Wenn der PC abstürzt, hat dein Lehrer wohl recht.

Klaus W. schrieb:
> Aber die Begründung mit dem verbrauchten Speicher ist absolut falsch.

Für die üblichen Betriebssysteme haste recht, das normal mit 
new/malloc-allokierte Zeug sollte dann weg sein.

Aber auch bei Windows muss nicht unbedingt jeder Speicher nach 
Prozessende freigegeben sein, Stichwort IPC/SharedMemory. Kann man aber 
gerne als Spezialfall bzw. bewusst getroffene Entwurfsentscheidung 
sehen, sowas zu nutzen.

Eher ist interessant, in welcher Reihenfolge bei globalen Objekten von 
Klassen die Konstruktoren aufgerufen werden :)

Milo schrieb:
> ... weil der reservierte Speicherbereich nach Programm-Ausführung
> nicht wieder freigegeben wird.

Ersetze "Programm-Ausführung" durch "Unterprogrammausführung". Dann 
passt es.

Sebastian W. schrieb:
> Das ist schlecht erklärt oder falsch verstanden.

Dann hat die Lehrkraft das selbst falsch verstanden, ich habe meinen 
Kenntnisstand ebenfalls im Unterricht geäußert und mir wurde die Antwort 
gegeben, dass es nicht der Fall wäre, dass das Betriebssystem den 
Speicher freiräumt, sondern der Speicherplatz der globalen Variablen bis 
zum Neustart des Rechners nicht mehr für andere Anwendungen zur 
Verfügung steht.

Milo schrieb:
> und mir wurde die Antwort gegeben, dass es nicht der Fall wäre, dass das
> Betriebssystem den Speicher freiräumt,

Das ist völliger Quatsch. Jedes Programm hat globale Variablen, denn die 
C- bzw. C++-Standard Library definiert auch welche (z.B. die 
errno-Variable). Da man globale Variablen nicht freigeben kann, würden 
die ja permanent Speicher belegen. Es wäre auch eine ziemliche 
Sicherheitslücke, wenn Programme den Speicher so vollmüllen könnten.

String-Literale und sonstige Konstanten werden genau wie globale 
Variablen im Speicher hinterlegt, typischerweise aber nochmal getrennt 
(schreibgeschützt). Würden die wie globale Variablen auch im Speicher 
bleiben, wäre das ziemlich mies!

Globale Variablen haben zwar gewisse Probleme, aber wenn sie "const" 
sind und idealerweise auch "static", sind sie okay. Größere Blöcke an 
konstanten Daten kann man auch nur so sinnvoll hinterlegen (z.B. 
Grafiken, Kennlinien). Windows hat da zwar noch einen anderen 
Mechanismus für, aber andere Systeme nicht.

Aus Sicht des Betriebssystems sind die unterschiedlichen Speichertypen 
des Programms alles das gleiche, einfach nur Teile eines linearen 
Adressraums. Einzelne Variablen kann das Betriebssystem sowieso nicht 
"sehen". Der Speicher eines Programms wird am Stück oder zerteilt in den 
RAM gelegt. Das Betriebssystem gibt diesen gesamten Bereich wieder frei 
nach Beenden des Programms, völlig egal ob da jetzt Stack, dynamisch 
allokierte Variablen oder globale Variablen drin sind. Dem 
Betriebssystem wäre es sogar egal wenn das Programm eine völlig andere 
Art der Speicherverwaltung nutzt.

Klaus W. schrieb:
> Dann eher Leerkraft, würde ich sagen

Leider gar nicht so selten. Ich hatte einen Professor, der in einer 
Vorlesung über Linux-Kernel-Entwicklung behauptet hat, es gäbe keinen 
virtuellen Speicher und alle Programme würden sich den selben Bereich 
teilen. Nicht der gleiche Unsinn, aber artverwandt. Insbesondere 
Leerpersonal scheint in solchen Bereichen besonders gut Bescheid zu 
wissen...

wie du siehst, "scheinst" du recht zu haben. Die Frage wäre also:
a) woher hat dein Lehrer seine Meinung und
b) was bräuchte es, ihn von etwas anderem zu überzugen?

k.A. schrieb:
> wie du siehst, "scheinst" du recht zu haben. Die Frage wäre also:
> a) woher hat dein Lehrer seine Meinung und
> b) was bräuchte es, ihn von etwas anderem zu überzugen?

Die Lehrkraft ist ehemals Software-Entwickler gewesen, unterrichtet aber 
den Großteil des Berufslebens Informationstechnik, ich habe es nicht 
notwendig die Lehrkraft von etwas zu überzeugen, davon wird die Note 1 
auch nicht besser.

Es ging mir ums Verständnis, ich habe in einer Prüfung Punktabzug 
bekommen, weil ich meine Variablen vor main() deklariert habe.

Lehrkräfte sind auch nicht unfehlbar, hätte es eine Note ausgemacht, 
wäre ich natürlich eher dahinter, die Lehrkraft vom Gegenteil zu 
überzeugen, so geht es mir nur darum zu lernen und zu verstehen, statt 
es einfach ohne zu akzeptieren, ohne es Verstanden zu haben.

Milo schrieb:
> k.A. schrieb:
> ich habe es nicht notwendig die Lehrkraft von etwas zu überzeugen,
> davon wird die Note 1 auch nicht besser.
> Lehrkräfte sind auch nicht unfehlbar, hätte es eine Note ausgemacht,
> wäre ich natürlich eher dahinter, die Lehrkraft vom Gegenteil zu
> überzeugen, so geht es mir nur darum zu lernen und zu verstehen, statt
> es einfach ohne zu akzeptieren, ohne es Verstanden zu haben.

Pragmatisch und intelligent. Hier nachzubohren hätte für dich keinen 
Vorteil (eher im Gegenteil).

Klaus W. schrieb:
> Ja klar.
> Aber nachdem der letzte Prozeß, der einen shared memory-Bereich nutzt,
> beendet ist, wird der auch freigegeben.
> Sogar unter Windows.
>
> Die Frage war aber nach globalen Variablen.

Wollte bloß darauf hinaus, dass halt der Begriff '(Shared) global' bei 
eingefleischten Windows-Betriebssystem-Fans mitunter auch für 
Synchronisationsprimitive oder IPC genutzt werden kann. Und da kann's 
halt eben durchaus sein, dass die Exe aus dem Taskmgr weg ist, der 
Speicher aber noch von nem anderen Prozess in Verwendung (-> halt im 
Sinne von global).

Egal.

Für globale Variablen in einem Programm ist die Sache klar, das OS muss 
alles, was beim Start eines Prozesses angeschubst wird, auch wieder 
aufräumen, wenn der Prozess terminiert.

Milo schrieb:
> Lehrkräfte sind auch nicht unfehlbar, hätte es eine Note ausgemacht,
> wäre ich natürlich eher dahinter, die Lehrkraft vom Gegenteil zu
> überzeugen

Sehr pragmatisch, aber so ganz gutheißen kann ich das nicht; am Besten 
lernt man doch in einer direkten Diskussion und ggf. gemeinsamen 
Recherchieren/Ausprobieren. Es ist schade wenn Schüler/Studenten 
falsches einfach abnicken, aber natürlich auch bedenklich, wenn Lehrer 
unbeirrbar auf ihrer falschen Position beharren. Das habe ich auch oft 
genug erlebt. Aber es ist für niemanden eine Neuigkeit, dass es im 
Bildungssystem schon lange nicht mehr um das Lernen an sich geht...

Milo schrieb:
> Punktabzug bekommen, weil ich meine Variablen vor main() deklariert
> habe.

Die Formulierung 'vor main' in diesem Zusammenhang macht mich stutzig.

Klaus W. schrieb:
> Ja klar.
> Aber nachdem der letzte Prozeß, der einen shared memory-Bereich nutzt,
> beendet ist, wird der auch freigegeben.

Schön wär's, System V Shared Memory ist da anderer Meinung.

Oliver S. schrieb:
> Die Formulierung ‚vor main’im Zusammenhang mit ‚global‘ macht für
> Variable eigentlich sehr viel Sinn.
>
> Oliver

Eigentlich nicht. Wenn man nur mit einer C-Datei arbeitet, dann ist main 
meist ganz unten und die Funktionen darüber.

Wenn da eine variable "vor main", also zwischen den Funktionen und main 
steht und nicht vorher declariert (oder es nur main gibt) dann ist diese 
Variable nur in main bekannt.

Zwar wäre die Begründung dann immer noch falsch (was nicht passieren 
darf), der Punktabzug jedoch gerechtfertigt. Wie gesagt, ich wurde nur 
bei der Formulierung stutzig, es gibt ja keinen Kontext (welches Niveau 
z.B.). Üblicherweise sagt man "außerhalb von main" oder "extern". Wenn

A. S. schrieb:
> Eigentlich nicht. Wenn man nur mit einer C-Datei arbeitet, dann ist main
> meist ganz unten und die Funktionen darüber.

Du überschätzt unser Niveau, der komplette Programmablauf findet in 
main() statt, vor main() waren nur die includes und eine 
Präprozessoranweisung und bei mir eben die Variablendeklarationen.

Frank M. schrieb:
> Wenn es nur eine Funktion main() gibt und keine weitere Funktionen, dann
> sind globale Variablen tatsächlich überflüssig.

Dies bestreite ich auch nicht, ich habe nur die Begründung der Lehrkraft 
hinterfragt, weil es für mich unlogisch klang.

Irgend W. schrieb:
> Die "errno" ist ein Sonderfall. Diese ist aus Anwendungssicht ja read only

Nein, errno ist nicht read-only.

Sebastian S. schrieb:
> Was aber wichtig ist: Das Programm muss regulär beendet werden denn erst
> dann wird "aufgeräumt".

Das ist Unsinn.

Klaus W. schrieb:

> Natürlich.
> Wenn ein Programm beendet wird, wird der Speicher für das nävhste
> verwendet.

Klar das machen unsichere Systeme so, damit man auch nach Programmende 
noch an dessen (geheime) Daten kommt. Klassisches Beispiel: image 
grabber beim Amiga.

Wenn es nur eine Methode in einem Programm gibt, ist egal, ob Variablen 
global oder lokal sind, weil die Programmlaufzeit gleich der Lebenszeit 
aller globalen und lokalen Variablen und Konstanten ist. Es könnte sein, 
dass der Compiler in beiden Fällen den gleichen Assembly-Code erzeugt.

Globale Variablen sind nur suboptimal, wenn es mindestens eine weitere 
Funktion oder Methode in dem Programm gibt.

Das wird die Lehrkraft zwar nicht überzeugen, weil Lehrkräfte die 
Weisheit mit dem Löffel gegessen haben und unfehlbar sind :) - Und zwar 
direkt nach ihrem Studienabschluss. (Ich hatte mal einen Lehrer, der hat 
tatsächlich argumentiert, dass er Recht habe, weil er das studiert hätte 
:) )

Der Speicher wird - wie bereits mehrfach beschrieben - vom Programm aus 
dem virtuellen Speicher alloziiert. Dazu wird der System-Call Malloc 
benutzt um vom Betriebssystemkernel den Speicher zugewiesen zu bekommen. 
Wird der Prozess beendet, wird sein Speicherbereich vom 
Betriebssystemkernel dealloziiert und steht anderen Prozessen zur 
Verfügung.

Ausnahmsweise kann der Speicher von einem weiteren Prozess alloziiert 
sein (bei Inter-Prozess-Kommunikation). Dann wird der Kernel den 
natürlich erst freigeben, wenn beide Prozesse beendet sind.

Almdahl schrieb:
> Dazu wird der System-Call Malloc
> benutzt um vom Betriebssystemkernel den Speicher zugewiesen zu bekommen.

malloc() ist kein Syscall, der dynamische Speicher wird von der 
C-Library verwaltet. Bei Bedarf(!) ruft sie den sbrk-Syscall auf, um 
mehr Speicher-Pages anzufordern.

Das stimmt offensichtlich - habe ich tatsächlich nicht gewusst und 
malloc für einen Syscall gehalten. Sorry für den Fehler.

Rolf M. schrieb:
> Auch sichere Systeme machen das. Sie nullen nur einfach den Speicher,
> bevor sie ihn dem anderen Programm zur Verfügung stellen.
>
> Almdahl schrieb:
>> Globale Variablen sind nur suboptimal, wenn es mindestens eine weitere
>> Funktion oder Methode in dem Programm gibt.
>
> Allerdings haben sie auch nur dann überhaupt einen Sinn.

Aber nur solange wie die localen Objecte nicht die Stackgöße 
überschreiten.

1

int main(int argc, const char *argv[])

2

{

3

  char myarr[10000000];

4

  myarr[sizeof(myarr)-1]=22; 

5

  return 0;

6

}

zeigt einem schnell wo die Grenzen sind.

demo schrieb:
> zeigt einem schnell wo die Grenzen sind.

Ich weiss jetzt nicht, was du meinst 😇

1

#include <stdio.h>

2

  2

3

  3 #pragma comment(linker,"/stack:16777216")

4

  4

5

  5 int main(int argc, const char *argv[])

6

  6 {

7

  7     char myarr[10000000];

8

  8     myarr[sizeof(myarr)-1]=22;

9

  9     printf("%d\n", myarr[sizeof(myarr)-1]);

10

 10     return 0;

11

 11 }

> gegeben, dass es nicht der Fall wäre, dass das Betriebssystem den
> Speicher freiräumt, sondern der Speicherplatz der globalen Variablen bis
> zum Neustart des Rechners nicht mehr für andere Anwendungen zur
> Verfügung steht.

Von welchen Versionen von Windows war da die Rede?
Für gewisse Werte von (alten) Windows' traf sowas tatsächlich und 
systematisch zu...
(damals waren wir noch klein und die PCs gross, gelle?)

SCNR