c++ Programm beenden? Befehl?

stegozilla

Lieutenant
Registriert
Sep. 2004
Beiträge
514
Hallo

Ich finde nirgends, welchen Befehl ich in c++ verwenden will, um ein Prog sofort beenden zu lassen (zb auf Auswahl best. Zahl im Menü).
Ich will nicht so ein Ding machen, dass mit ...solange wie !wahr, ausführen... funktioniert.
Gibts da nicht sowas wie close() oder terminate()?

Hat hier einer davon Ahnung?
 
Schau Dir mal exit() an.

Allerdings halte ich von einem derartigen Programmierstil überhaupt nichts! Dadurch werden Programme unwartbar, unübersichtlich, ...
Nicht zu vergessen, das bei exit() das Programm nicht korrekt beendet wird. D.h. der allokierte Speicher wird nicht freigegeben, ...
D.h. auf Dauer produzierst Du damit ein instabiles System.

Es schadet nichts sich ein bisschen den Kopf über eine sinnvolle Programmstruktur zu zerbrechen und ein Programm korrekt zu beenden. D.h. das die Funktion main() einfach normal beendet wird.

z.B.:
Code:
int main(int argc, char* argv[])
{
  bool bReady = false;

  while( !bReady )
  { 
    drawMenu();
    switch( getMenuSelection() )  
    {
        case TERMINATE_PROGRAM:
          bReady = true;
        break;
    }
  }
  return 0;
}

MfG

Arnd
 
Zuletzt bearbeitet:
Hallo,

Mit "return;" kanns du Methoden abbrechen die keinen Rückgabewert liefern, also void sind. Mut "exit(int Zahl)" kanns du ein Programm beenden. Die Zahl die bei der Funktion "exit()" zu spezifizieren ist, kannst du (ziemlich) frei wählen.

Aber für gewöhlich, gibt man "exit(0)" an, falls das Programm korrekt terminiert wurde oder "exit(-1)" falls das Programm durch einen Fehler abgebrochen wurde. Diese Zahlen werden an das Betriebssystem gegeben, und dann weiss das Betriebsystem warum das Programmende eingetreten ist. Wahrscheinlich gibts noch andere Zahlen, die man angeben kann, aber schlussendlich ist es (fast) egal.

Es kann sein, dass sich die Funktion "exit" in einem Paket befindet, das du noch includen muss (versuche es mal mit "#include<cstdlib.h>").

Edit: Ich kann mich meinem Vorgänger nur zum Teil anschliessen. Wenn man raus muss, muss man raus. Wichtig ist allerdings, alle erzeugte Objekte freizugeben. Es lohnt sich also eine Methode zu schreiben, die alle Objekte löscht, und dann einen exit() ausführt.
 
Zuletzt bearbeitet:
mal ganz abgesehen davon das ich exit auch nicht besonders mag. aber wird nicht beim programmende sowieso der ganze speicher des prozesses vom betriebsystem freigegeben? das einzige worauf man dann aufpassen muss ist was man in speicher geschrieben hat der nicht direkt zum prozess gehört.
 
Z.B. im Kontext von Windows mit DLLs trifft dies nicht zu. Für DLLs wird auch Systemspeicher bzw. Systemressourcen reserviert. Der dann nicht mehr freigegeben wird.

Unter Window95 war das ganz interessant zu sehen wie dem Windows der Speicher für die Icon Handles ausgegangen ist. Der Desktop war dann nur noch Pixelmüll.

Der einzige Kontext in dem ein exit() eventuell eine Berechtigung hätte, wäre beim überladen von Systemfunktionen. Wenn z.B. ein new oder malloc keinen Speicher mehr reservieren kann. Dann wäre ein exit gerade noch zu akzeptieren.
Aber selbst dann gehört eine vernünftige Fehlermeldung dazu und eben besser noch ein "normales" Programmende.

Wenn man sich konsequent die Mühe macht Fehlerfälle abzufragen, ist es auch kein Problem dies umzusetzen.

In grösseren Projekten macht es unheimlich Spass heraus zu finden warum ein Programm sich plötzlich beendet. Vor allem wenn dann noch mehrere exit() eingebaut sind.

Aber man muss jeden Fehler mal selbst gemacht haben :-). Das ist eben meine bisherige Erfahrung.
Mit exit() kann man sich das Leben leicht machen, aber später den Code zu warten vor allem wenn er von jemand anderem geschrieben wurde wird damit nicht einfacher.

MfG

Arnd
 
Zuletzt bearbeitet:
DAnke für die Tipps, ich werde es heute gleich mal ausprobieren.
 
dann sind wir uns ja einig. um nochmal eine alternative anzubieten: warum nimmst du nicht exceptions? wenn du alles schön mit klassen gemacht hast die ordentliche destruktoren haben, dann kannst du damit dein programm genauso schnell und einfach beenden wie mit exit. mit dem unterschied das es deutlich einfacher zu debuggen ist und das programm in der regel richtig beendet wird(sprich alle resourcen freigegeben werden, solange du den rest auch ordentlich programmiert hast ;)).

sowas sollte man allerdings natürlich nur im feherfall benutzen. aber ne andere anwendung für exit kann ich mir sowieso schlecht vorstellen.
 
exit mit fehlercode ist ok. immer einen anderen fehlercode verwenden und schon kannste später programme auch warten. ressourcen werden durch das os freigegeben (evt. gabs bei win95 ein bug)
eleganteste version ist aber ne exception zu schmeissen, die du im main abfängst und auswertest. so kannste auch div by zero etc. abfangen und unschöne "abstürtze" vermeiden.
 
Cleaner57 schrieb:
... oder "exit(-1)" falls das Programm durch einen Fehler abgebrochen wurde...
Das stimmt leider nicht. Standardkonform ist nur exit(EXIT_SUCCESS) (== 0) oder exit (EXIT_FAILURE) (== 1). Negative Codes darf man niemals verwenden, da üblicherweise die Shell mit dem dem Betriebssystem so kommuniziert. Gerade der Code -1 bedeutet hier, dass keine Shell gestartet werden konnte. Am besten nur positive Codes <= 127 verwenden, noch besser, nur die obigen beiden Defines benutzen.

Bei exit wird sehr wohl der Speicher korrekt freigegeben - zumindest teilweise. Insbesondere werden alle Funktionen aufgerufen, die mit atexit registriert wurden.
Auch wird von allen statischen Objekten der Destruktor korrekt aufgerufen.

Nur automatische Objekte werden nicht zerstört, was u.U. zu Ressourcen-Löchern führt, insbesondere bei Prozess-übergreifenden Ressourcen. Automatische Objekte sind übrigens ganz "normalen" Variablen:

Code:
static istringstream is; /// statisches Objekt, wird zerstört

int main()
{
  ofstream fout; /// automatisches Objekt
  ...
  exit(1); /// fout wird nicht zerstört, is wird zerstört
}

Das ist jetzt aber kein Freibrief dafür, static zu verwenden. Das solltest du nach Möglichkeit niemals.
 
Das wird nicht nur in Win95 so gewesen sein. Die Verwaltung von DLLs i.a. und insbesondere von MFC DLLs ist seither nicht stabiler geworden :-). Es ist keine gute Idee eine MFC DLL einfach so abzubrechen.

Die Variante mit der Exception gefällt mir ja. Das wäre zumindest ein Standard konformer Weg um aus dem Programm raus zu kommen.

Auch wenn nur exit()s mit verschiedenen Rückgabewerten verwendet werden sollten. Mir gefällt ein Haus mit vielen Ausgängen nicht so besonders gut. Es lässt sich einfach schlechter kontrollieren wer wann wo rausgeht. Ein Ausgang ist da wesentlich leichter zu handhaben.

MfG

Arnd
 
Zurück
Oben