Das deutsche QBasic- und FreeBASIC-Forum

[TimesChange]

Zum Beenden eine Programms mit END habe ich eine Frage:

Kann ich ein Programm problemlos an jeder Stelle des Codes mit END beenden?
Oder vielleicht besser anders gefragt: Unter welchen Umständen reicht es nicht aus, ein Programm mit END zu beenden?

Hintergrund ist der Satz aus der Befehls-Referenz "Wenn das Programm mit END beendet wird, dann werden Variablen und Speicher nicht automatisch zerstört".

Ich verstehe das so:
END beendet ein Programm, der für Programmcode und Variablen benötigte Speicher wird vollständig wieder frei gegeben.
Der nun freie Speicherbereich kann (wird) aber immer noch die Inhalte aus dem soeben beendeten Programm enthalten.

Ist meine Interpretation richtig?

Grüße
Rainer

Die Frage klingt etwas *blöd*, denn

[nemored]

In der Regel räumt das Betriebssystem nach Programmende ja selbst auf.
Betroffen sind bei END alle eigenen Datentypen (UDTs), die in irgendeiner Form eigenen Speicher belegen (z. B. über ALLOCATE oder IMAGECREATE), der dann auch selbst wieder aufgeräumt werden muss. In der Regel läuft das über den UDT-Destruktor (siehe DESTRUCTOR) - dieser wird aber bei END nicht aufgerufen. Modul-Destruktoren dagegen schon.

Wie gesagt, normalerweise sollte trotzdem nichts schlimmes passieren, weil das Betriebssystem selbst aufräumt; zum sauberen Programmieren gehört es aber allemal, keinen Müll rumliegen zu lassen.
_________________
Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1.

[TimesChange]

Wenn ich nochmal zu den UDTs nachfragen darf:

Bei UDT's, denen nicht mit ALLOCATE Speicher zugewiesen wird, sondern nur per DIM, wird durch ein END an irgendeiner beliebigen Stelle des Programms (also Beendigung auch auch in einer Sub oder Function möglich)
der komplette Speicherbereich wieder freigegeben?

Als z.B. so etwas:

[nemored]

Es geht mir nicht um UDTs, die in einen ALLOCATE-Speicher gelegt werden (diese solltest du sowieso zum Programmende selbst zerstören), sondern um UDTs, die in ihrem Konstruktor selbst Speicher anlegen und im Destruktor wieder freigeben. Aber solange du solche Sachen nicht machst, musst du dir um END keine Sorgen machen.

Ansonsten scheint mir der Umgang mit END ein Stück weit eine Glaubensfrage zu sein. Wenn es umsetzbar ist, sollte man das Programm einfach am Ende auslaufen lassen. Allerdings ist das nicht immer möglich (zumindest solange man auf "GOTO ende" verzichten möchte ...)

Einen Destruktor zu bauen ist immer dann sinnvoll, wenn am Ende noch aufgeräumt werden muss - Speicherfreigabe z. B. (in deinem Mini-Beispiel nicht nötig), wenn die Daten weggespeichert werden müssen oder sonst irgend etwas in der Art. Verkettete Listen sind so ein Beispiel, wo er wegen Speicherfreigabe dringend nötig ist
_________________
Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1.

[TimesChange]

[dreael]

Früher in der Commodore Amiga-Zeit war dies noch ein relevantes Problem, dass ein inzwischen beendeter Prozess beispielsweise verwaiste Screens und Windows hinterlassen konnte... Hatte ich damals im AmigaBASIC hie und da gehabt: Während der interne Befehlssatz, sprich Interpreter/Laufzeitumgebung sich noch recht gut um ein Aufräumen beim Beenden kümmerte, konnte es bei einem "CALL AllocMem&" (direkt aufs Betriebssystem-API gehen) sehr schnell einmal verwaiste Ressourcen geben.

In der Zwischenzeit würde so etwas bereits als gröbere Sicherheitslücke im Betriebssystem gelten. Bestandteil vom heute üblichen Speicherschutz von User Space-Programmen ist es auch, Ressourcen zu überwachen und diese ggf. bei einem "taskkill /force" (Windows) bzw. "kill -9" (Linux) vollständig abzuräumen.

Grundsätzlich ist aber schon besserer Programmierstil, alles, was man angefordert hat, am Schluss auch wieder freizugeben, so dass die sich Software auch für ein Umfeld ohne Speicherschutz eignen würde.

Auf Kernel Mode-Ebene dagegen gibt es den Speicherschutz dagegen nicht; dort muss wie zu Beginn genannt sauber gearbeitet werden, denn fehlerhafte Treiber führen bekanntlich zum berühmt-berüchtigen Bluescreen (Windows) bzw. zu einer Kernel panic (Linux).

Zusammengefasst: Bei "normalen" Anwendungen wie FreeBasic-Programm im User Space profitiert man vom Betriebssystem von ziemlich starken Sicherheitsgurten, was überhaupt erst effiziente IDEs ermöglicht, ohne ständig Reboot-Abstürze zu riskieren, wie dies in der Amiga/MS-DOS-Zeit noch üblich war.
_________________
Teste die PC-Sicherheit mit www.sec-check.net

[Jojo]

nemored: Da das OS sich selbst um die Freigabe des Speichers kümmert, sind verkettete Listen ein eher schlechtes Beispiel. Ein besseres wäre z.B. ein UDT, der die komplette Konfiguration des Programms enthält und diese im Destruktor z.B. in eine Konfigurationsdatei schreiben würde.
_________________
» Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.

[nemored]