c - malloc - free

ich schrieb:
> Das Programm läuft quasi in einer Endlosschleife, wodurch ich es zu 99%
> mit dem X schließe.

Das bedeutet, daß Du es "abschießt", und daß es unter Windows läuft.

Von einem Prozess belegter Speicher (und andere Ressourcen) wird beim 
Beenden des Prozesses automatisch freigegeben; Du musst Dich also nicht 
zwingend darum kümmern, free() aufzurufen.

Sauberer wäre allerdings ein Programmdesign, das einen sauberen Abbruch 
ermöglicht - wenn Du beispielsweise eine geöffnete Datei hast, in die 
Dein Programm hineinschreibt, wird diese beim "Abschießen" nicht sauber 
geschlossen.

Rufus Τ. F. schrieb
>...
> Das bedeutet, daß Du es "abschießt", und daß es unter Windows läuft.
>
> Von einem Prozess belegter Speicher (und andere Ressourcen) wird beim
> Beenden des Prozesses automatisch freigegeben;
>
> ...

So sollte es eigentlich sein - aber...

Und wenn es eine dialogbasierte Applikation ist kommts ins WM_CLOSE oder 
WM_DESTROY

1

case WM_CLOSE:

2

    {

3

        free(blubb);

4

        EndDialog(hwndDlg, 0);

5

    }

Walter K. schrieb:
> So sollte es eigentlich sein - aber...

Was magst Du damit meinen?

ich schrieb:
> Das Programm läuft quasi in einer Endlosschleife, wodurch ich es zu 99%
> mit dem X schließe.
>
> Quasiablauf:
> - malloc(...)
> - while(1){...}
> - free(...);
>
> Nach meinem Verständnis erreiche ich free() nie. Wie löst man so ein
> Problem elegant?

Es ist gelöst, schliesst du das Fenster in dem das Programm läuft (kann 
ja nur eine Konsolenanwendung sein), wird auch der Speicher wieder 
freigegeben.

Aber so ein Programm ist natürlich Scheisse. Man sollte Programme nicht 
abschiessen mmüssen, sondern ordnungsgemäss herunterfahren können, mit 
Close-Button, mit Close-Menükommando, mit Tastatur falls es auf Eingaben 
wartet, mit allem was angemessen ist.

Das WM_CLOSE wäre für ein Windows-Fenster-Programm die richtige Wahl, 
dafür muss man halt ein richtiges Windows Programm schreiben.

Man bedenke auch, daß Programme die in while(1) Endlosschleifen 
stecken,s ständig den prozessor auslasten und das System belasten und 
falls es einen Akku giubt den leersaugen und andere Programme nicht zum 
Zug kommen lassen. Schon alleine daher ist so eine Endlosschleife eher 
schlecht. Man baut event driven Programme, ereignisgesteuerte, deren 
Hauptschleife beendet wird wenn das Programm beendet werden soll.

Falls das malloc eine immer gleiche Grösse anfordert, sollte man den 
Speicher eh statisch anlegen.

char buffer[1234];
while(1) { ... };

Dann staret das Programm nur wenn genug Speocher verfügbar ist.

Michael B. schrieb:
> Das WM_CLOSE wäre für ein Windows-Fenster-Programm die richtige Wahl,
> dafür muss man halt ein richtiges Windows Programm schreiben.

Weißt du so ad-hoc, ob at_exit-Hooks beim Close-Button noch ausgeführt 
werden würden?

Heiko L. schrieb:
> Weißt du so ad-hoc, ob at_exit-Hooks beim Close-Button noch ausgeführt
> werden würden?

Ein echtes Windows-Programm könnte er mit X nicht beenden, wenn es nicht 
auf WM_CLOSE reagiert, zumindest mit DefWindowsProc.

Er hat ein Commandozeilenprogramm, das wird bei Close per X der Console 
nur abgeschossen, kein at-exit.

René H. schrieb:
> Naja, Windows ist nicht das einzig existierende Betriebssystem.

Ach. Das hätte ich ja jetzt echt nicht gedacht.


Der Threadstarter aber verwendet offensichtlich Windows, weil er sonst 
seine Konsolenfenster/-Programme nicht auf diese Art schließen würde: 
"wodurch ich es zu 99% mit dem X schließe".