Warum kein system("PAUSE"); vor und nachteile ?

[CStoll]

Das steht auch in der Konsolen-FAQ - Stichwort "Automatisches Schließen verhinern".

[Bassmaster]

ok thx

[*D*Evil]

Und genau das solltest du dann nicht nutzen, weil aus einem mir unbekannten Grund da immer noch eine nicht wirklich richtige alternative steht: http://www.c-plusplus.net/forum/viewtopic-var-p-is-1407480.html#1407480 ist da schon um einiges besser ...

[Nexus]

Trotzdem finde ich system("pause") gar nicht so übel. Bei std::cin.get() muss man womöglich noch den Puffer leeren, und manchmal sind zwei Eingaben erforderlich. Zudem funktioniert nur die Enter-Taste.

Solange man die Konsole nur zum Lernen benötigt und nicht ein ernsthaftes Projekt damit verfolgt oder etwas portieren will, finde ich system("pause") gerechtfertigt - es ist eben am einfachsten am Anfang. Und was das langsam angeht, das dürfte eh keine Rolle spielen. Meistens hat man den system -Aufruf ja nur einmal am Schluss, eventuell noch zwischendrin. Man sollte sich einfach der Nachteile bewusst sein und, wenn der Zeitpunkt gekommen ist, davon wegkommen.

[Fellhuhn]

Davon abgesehen das der Thread schon fast ein Jahr alt ist:

Warum nicht einfach das Programm aus einer Konsole heraus starten? Dann braucht man so einen Unfug gar nicht.

[Nexus]

Fellhuhn schrieb:

Warum nicht einfach das Programm aus einer Konsole heraus starten?

Weil es mühsam ist, nicht einfach in der IDE einen einzigen Knopf zu drücken

[Tanren]

Nexus schrieb:

Fellhuhn schrieb:

Warum nicht einfach das Programm aus einer Konsole heraus starten?

Weil es mühsam ist, nicht einfach in der IDE einen einzigen Knopf zu drücken

Jede vernünftige IDE lässt das Fenster entweder automatisch offen oder hat eine eigene eingebaute Konsole die auch offen bleibt.

IMHO ist der Hauptgrund warum man system("PAUSE") nicht verwenden soll der das es einfach völlig überflüssig ist.

[Dravere]

Nexus schrieb:

Fellhuhn schrieb:

Warum nicht einfach das Programm aus einer Konsole heraus starten?

Weil es mühsam ist, nicht einfach in der IDE einen einzigen Knopf zu drücken

<CTRL>+<F5> (zumindest unter MSVC)
Dies startet allerdings nicht den Debugger, kann man dann aber im Nachhinein starten lassen. Dafür hat es am Ende automatisch ein "Bitte drücken sie eine beliebige Taste...".

Grüssli

[Fellhuhn]

Nexus schrieb:

Fellhuhn schrieb:

Warum nicht einfach das Programm aus einer Konsole heraus starten?

Weil es mühsam ist, nicht einfach in der IDE einen einzigen Knopf zu drücken

Selbst wenn sonst nichts greift, warum nicht einfach einen Breakpoint setzen?

[Nexus]

Fellhuhn schrieb:

Selbst wenn sonst nichts greift, warum nicht einfach einen Breakpoint setzen?

Oder warum nicht einfach system("pause") verwenden, wenn man damit keine Probleme hat und auch in absehbarer Zukunft keine damit haben wird? Dann kann man Programme auch direkt als Anwendung aus dem Windows Explorer starten.

[unskilled]

Nexus schrieb:

Fellhuhn schrieb:

Selbst wenn sonst nichts greift, warum nicht einfach einen Breakpoint setzen?

Oder warum nicht einfach system("pause") verwenden, wenn man damit keine Probleme hat und auch in absehbarer Zukunft keine damit haben wird? Dann kann man Programme auch direkt als Anwendung aus dem Windows Explorer starten.

endlich ma jmd, der das auch so sieht... Klar kann man auch dies, das und jenes machen und dann trotzdem noch unendlich viele Nachteile haben - aber man kann auch einfach system ("pause"); nutzen und sich freuen, dass man echt nix machen muss und trotzdem alles genau so gut klappt... Btw seh ich auch keinen Nachteil bei so einer Fkt:
- sie ist meines erachtens nacht os-unabhängig, weil diese fkt von jedem os geboten wird...
- die Geschwindigkeit (was sonst immer das größte Prob ist - von wegen extra shell öffnen, ...) ist eh egal, weil danach eh erst ma auf ne eingabe gewartet werden muss...

bb

[Nexus]

Gut, dass ich nicht der einzige bin

Naja, bei paar Dingen habe ich sowieso das Gefühl, viele Leute halten sie für böse, aber wirklich Argumente gegen einen bestimmten Anwendungsfall gibts nicht (soll natürlich nicht heissen, dass system keine Nachteile hätte)...

[Badestrand]

Nexus schrieb:

Naja, bei paar Dingen habe ich sowieso das Gefühl, viele Leute halten sie für böse, aber wirklich Argumente gegen einen bestimmten Anwendungsfall gibts nicht (soll natürlich nicht heissen, dass system keine Nachteile hätte)...

Ist wahrscheinlich ähnlich goto oder dass Funktionen nicht länger als X Zeilen lang sollen. Man sollte sowas nicht großzügig überall im Code einsetzen, aber um schnell mal was zu erreichen oder wenn's in einer konkreten, eingegrenzten Situation nun mal Vorteile hat (z.B. schnellster Wildcard-Match-Algorithmus den ich kenne arbeitet mit 'goto's), kann man's ja ruhig machen.

[LordJaxom]

- Konsolenprogramme beenden sich. Wenn mal ein system("pause") vergessen wird schimpft der Kunde
- pause.exe gibt's nicht auf jedem System.
- seltsamerweise ist noch niemand auf die Idee gekommen, eine Ausgabe per system("echo hallo") zu coden, aber die einfache Aufgabe, auf eine Eingabe zu warten, soll an das System delegiert werden.

Vor allem den letzten Punkt finde ich unter dem Gesichtspunkt, dass man doch Programmieren lernen möchte, eher bedenklich.

[_matze]

Nexus schrieb:

Trotzdem finde ich system("pause") gar nicht so übel. Bei std::cin.get() muss man womöglich noch den Puffer leeren, und manchmal sind zwei Eingaben erforderlich. Zudem funktioniert nur die Enter-Taste.

Wäre da nicht "while(!_kbhit());" eine Alternative?

[pumuckl]

_matze schrieb:

Wäre da nicht "while(!_kbhit());" eine Alternative?

klar. Du kannst auch die Funktion Wurstbrot() aufrufen und hoffen dass es funktioniert - Tatsache ist, dass weder system("pause") noch _kbhit() Standardkonform sind und damit nur eingeschränkt oder garnicht portabel.

Tatsache ist auch, dass das "Hilfe-meine-Konsole-geht-zu"-Problem kein C++-Problem ist, und auch nur zum Teil ein OS-Problem, sondern vielmehr ein Anwenderproblem. Wenn der Anwender Konsolenprogramme nicht aus der Konsole sondern vom Desktop aus startet muss er damit rechnen dass es Effekte gibt die beim Start aus der Konsole nicht vorkommen.
Man könnte natürlich argumentieren dass das trotzdem möglich sein sollte, weil ja viele Anwender ihre Programme vom Desktop aus starten - es gibt aber auch einige Anwender die nur von der Konsole aus arbeiten, sollte denen dann nicht auch ermöglicht werden, ihre GUI-Anwendungen einfach aus der Konsole zu starten? Ich möchte von meinem DOS-Rechner aus (oder auf meinem Server der eh keine grafische Oberfläche hat) ein Programm starten das eine GUI hat - also hätte ich gern einen Einzeiler á la system("pause") der mir in einem Kommandozeilen-OS mal eben on the fly einen grafischen Desktop aufbaut damit ich die GUI meines Programms sehe. </ironie>

mein Fazit ist, es gibt zwei Möglichkeiten:
a) Ich schreibe ein standardkonformes portables Konsolenprogramm. Konsolenprogramme sollten von der Konsole aus gestartet werden und bracuhen daher keinen "halt-mir-die-konsole-offen"-Schnickschnack.
b) Ich schreibe ein Konsolenprogramm das vom Dekstop meines grafischen OS aus gestartet werden kann und offen bleiben soll. Das ist dann eh nicht portabel (nicht jedes OS ist grafisch), also kann ich auch nichtportable Funktionen benutzen.

[_matze]

pumuckl schrieb:

Tatsache ist, dass weder system("pause") noch _kbhit() Standardkonform sind und damit nur eingeschränkt oder garnicht portabel.

Das ist mir, ehrlich gesagt, ziemlich egal. Portabilität interessiert mich nicht. Ich schreibe beruflich und privat ausschließlich Windows-Anwendungen. _kbhit ist (unter Win) eine gute Altertative zum cin.get, bei dem wie gesagt die Enter-Taste gedrückt werden muss.

pumuckl schrieb:

Man könnte natürlich argumentieren dass das trotzdem möglich sein sollte, weil ja viele Anwender ihre Programme vom Desktop aus starten - es gibt aber auch einige Anwender die nur von der Konsole aus arbeiten, sollte denen dann nicht auch ermöglicht werden, ihre GUI-Anwendungen einfach aus der Konsole zu starten?

Wenn ich dein Zitat so für sich stehen lasse, dann würde ich mal sagen: problemlos möglich!

pumuckl schrieb:

Ich möchte von meinem DOS-Rechner aus (oder auf meinem Server der eh keine grafische Oberfläche hat) ein Programm starten das eine GUI hat

Das natürlich nicht...

pumuckl schrieb:

mein Fazit ist, es gibt zwei Möglichkeiten:
a) Ich schreibe ein standardkonformes portables Konsolenprogramm. Konsolenprogramme sollten von der Konsole aus gestartet werden und bracuhen daher keinen "halt-mir-die-konsole-offen"-Schnickschnack.
b) Ich schreibe ein Konsolenprogramm das vom Dekstop meines grafischen OS aus gestartet werden kann und offen bleiben soll. Das ist dann eh nicht portabel (nicht jedes OS ist grafisch), also kann ich auch nichtportable Funktionen benutzen.

Ich wähle guten Gewissens b). Wer a) wählt, kann ja während der Entwicklungsphase trotzdem mit nicht standardkonformen Methoden dafür sorgen, dass seine Win-Konsole offen bleibt, und diese dann zum Schluss entfernen. Optimaler Komfort während der Entwicklung und als Ergebnis totale Portabilität!

[LordJaxom]

_matze schrieb:

Wer a) wählt, kann ja während der Entwicklungsphase trotzdem mit nicht standardkonformen Methoden dafür sorgen, dass seine Win-Konsole offen bleibt, und diese dann zum Schluss entfernen. Optimaler Komfort während der Entwicklung und als Ergebnis totale Portabilität!

Wenn schon, dann sollte man das über Release/Debug und die entsprechenden Makros entfernen lassen. Selbst etwas zu Debugging-Zwecken einzubauen (mit dem Ziel, es später manuell wieder zu entfernen) verleitet dazu, es zu vergessen.

Und den optimalen Komfort erreicht man auch durch eine vernünftige IDE, die das für einen macht - das ist sogar optimaler (:p), weil kein zusätzlicher Code nötig ist.

[*john 0]

unskilled schrieb:

- sie ist meines erachtens nacht os-unabhängig, weil diese fkt von jedem os geboten wird...

Nein, das ist dann ein reines DOS/Windows Programm. Man sollte beim Programmieren als erstes lernen, daß man sich auf zugesicherte Eigenschaften der jeweiligen Umgebung verläßt, und darüber hinaus keinerlei implizite Erwartungen an die Umgebungen haben.

Wenn man reines C++ programmiert, dann hat das system("PAUSE") rein gar nichts zu suchen.

[Dravere]

Wann benutzt ihr eigentlich system("PAUSE") , bzw. ein std::cin.get() und co?
Also ich persönlich verwende sowas nur in meiner Testanwendung und früher in Übungsbeispielen. Ansonsten muss bei mir normalerweise der Benutzer ein Kommando eingeben, sei es eine 0 oder ein "quit", damit überhaupt erst das Konsolenprogramm beendet wird.

Daher:
- In Übungsbeispielen ist es ein Anfänger. Anfängern sollte man erst gar nie etwas falsches beibringen, auch nicht, wenn es teilweise richtig ist. Sie sollten, wenn sie C++ lernen, reines korrektes C++ auch lernen.
- In der Testanwendungen habe ich persönlich immer bereits ein wait() vorprogrammiert. Da ich eigentlich immer die gleiche Testanwendung verwende, kann ich immer dieses wait() benutzen. Ich habe das Ding auch in einem "Test.hpp" drin, wo ich allerhand anderer für mich kleine Tools zum testen habe.

Ich selber benutze kein system("PAUSE") auch an Stellen, wo es keine Probleme machen würde, aus dem einfachen Grund, weil ich mich erst gar nicht an etwas gewöhnen will, was Fehler verursachen könnte. Und man gewöhnt sich an so Dinge schneller als einem lieb ist.

"Ach nur hier, das ist eine kleine Anwendung!"
"Das wird sicher auch gehen!"
"Ich korrigiere es dann später noch um!"
"Momentan macht es keine Probleme!"
usw.

Ich würde es mit dem Autofahren mit Sandalen vergleichen. Das kann gut gehen, das kann tausend Male gutgehen. Man gewöhnt sich dran, es hat ja noch nie ein Problem verursacht. Bis es dann mal soweit ist und die Situation kommt, wo du mit richtigen Schuhen kein Problem gehabt hättest. Nur weil du zu faul warst, schnell die Schuhe anzuziehen ... Nur weil du zu faul warst, ein zwei Zeilen mehr zu schreiben
Deshalb es erst gar nicht verwenden, es verhindert Probleme, auch wenn diese erst in 10 Jahren oder sonst wann auftauchen!

Grüssli