c - malloc - free

[ich (Gast)]

Hallo zusammen,

kleine konzeptionelle Frage. Ich bastle zur Zeit an einem Programm bei 
dem ich über malloc Speicher reserviere und den Inhalt einer Datei lade. 
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?

[Rufus Τ. F. (rufus)]

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.

[ich (Gast)]

Ok, das heißt, dass ich die klassiche Abfrage nach "q" oder "ESC" als 
saubere Lösung einbauen sollte.

[Walter K. (walter_k488)]

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...

[Mix (Gast)]

Alles hier dokumentiert:
https://docs.microsoft.com/en-us/windows/console/registering-a-control-handler-function

[Timmo H. (masterfx)]

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

case WM_CLOSE:
    {
        free(blubb);
        EndDialog(hwndDlg, 0);
    }

[Rufus Τ. F. (rufus)]

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

Was magst Du damit meinen?

[Michael B. (laberkopp)]

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.

[Heiko L. (zer0)]

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?

[René H. (Gast)]

Rufus Τ. F. schrieb:
> Walter K. schrieb:
> So sollte es eigentlich sein - aber...
>
> Was magst Du damit meinen?

Naja, Windows ist nicht das einzig existierende Betriebssystem.
Es sollte so sein, ist gar die Regel, aber mitnichten garantiert. Nicht 
mit C/C++

Grüsse,
René

Add: https://de.m.wikipedia.org/wiki/Speicherleck

[Michael B. (laberkopp)]

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.

[Rufus Τ. F. (rufus)]

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".

[Nop (Gast)]

Michael B. schrieb:

> Man baut event driven Programme, ereignisgesteuerte, deren
> Hauptschleife beendet wird wenn das Programm beendet werden soll.

Und das kann man auch gut in einer Endlosschleife machen, wo man auf 
irgendwas blockiert, bis eine Aktion kommt. Beispielsweise kann man auf 
I/O blockierend warten, was man dann reinpipen kann.

[georg (Gast)]

ich schrieb:
> Nach meinem Verständnis erreiche ich free() nie

Trivial: statt while (1) while (kein Stopbefehl).

Georg

[René H. (Gast)]

Rufus Τ. F. schrieb:
> 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".

Das X gibts auch nicht nur bei Windows :-).

Grüsse,
René

PS: Anlage ist SLES 11...