C++ Visual C++ 2008 EE Frage

[dummie]

Hallo,
hab ne ganz einfache Frage bei dem Programm Visual C++ 2008 Express Edition.

Wenn ein Code compiliert und dann bei Ausführung entsprechend am Bildschirm
ausgegeben wird, verschwindet das DOS-Fenster ("cmd.exe", wenn es sich zB nicht
um grafische Programme handelt) wieder nach Ausgabe bzw. Durchführung.

Wie kann man das Ausgabefenster (bzw. Eingabeforderungsfenster, cmd.exe-Fenster)
stehen lassen ?

 

[Tumbleweed]

Ctrl+F5

Oben im Menü verzeichnet als "Starten ohne Debugging".

Alternativ: Eingabe abfragen am Ende cin.get();

 

[Spartaner117]

Wenn die WinAPI zur verfügung steht, kannst du auch system("pause"); benutzen.

 

[XunnD]

Ich denke, um die Portierbarkeit zu gewährleisten, ist cin.get() die elegantere Lösung.

"pause" ist ja nichts weiter als eine Executable, die das gleiche macht.

 

[asdfman]

SLEEP(3)                   Linux Programmer’s Manual                  SLEEP(3)



NAME
       sleep - Sleep for the specified number of seconds

SYNOPSIS
       #include <unistd.h>

       unsigned int sleep(unsigned int seconds);

DESCRIPTION
       sleep()  makes  the  calling  process  sleep until seconds seconds have
       elapsed or a signal arrives which is not ignored.

RETURN VALUE
       Zero if the requested time has elapsed, or the number of  seconds  left
       to sleep.

CONFORMING TO
       POSIX.1-2001.

BUGS
       sleep()  may be implemented using SIGALRM; mixing calls to alarm(2) and
       sleep() is a bad idea.

       Using longjmp(3) from a signal handler or  modifying  the  handling  of
       SIGALRM while sleeping will cause undefined results.

SEE ALSO
       alarm(2), signal(2)

COLOPHON
       This  page  is  part of release 3.01 of the Linux man-pages project.  A
       description of the project, and information about reporting  bugs,  can
       be found at http://www.kernel.org/doc/man-pages/.



GNU                               1993-04-07                          SLEEP(3)

 

[7H3 N4C3R]

Ich denke, um die Portierbarkeit zu gewährleisten, ist cin.get() die elegantere Lösung.

"pause" ist ja nichts weiter als eine Executable, die das gleiche macht.

cin.get() ist zwar portabel, du hast aber auch keine Garantie, dass es zuverlässig funktioniert.

"pause" ist zwar "Pfusch", funktioniert aber wenigstens zuverlässig. Für erste Tests reicht das völlig.

 

[DaBigTank]

wie wäre es mit "getch()"?!

Dafür musst aber dann die conio.h includen

 

[mr.Gr3y]

Würde es auch mit "getch();" machen.

 

[asdfman]

conio.h ist ja mal das portabelste überhaupt :E

 

[Tumbleweed]

Wo es sich ja gerade ums Visual Studio dreht - gibt es eine Möglichkeit oben in dem "members" drop-down nur Methoden anzuzeigen und nicht meine unzähligen Variablen? (jetzt bezogen aufs Visual C# 2k5 EE)

 

[XunnD]

cin.get() ist zwar portabel, du hast aber auch keine Garantie, dass es zuverlässig funktioniert.

"pause" ist zwar "Pfusch", funktioniert aber wenigstens zuverlässig. Für erste Tests reicht das völlig.

Wieso sollte man für so eine Funktionalität erst noch per system("pause") einen neuen Prozess spawnen? Ich bitte Euch - schießt mal nicht mit Kanonen auf Spatzen!

 

[1668mib]

Warum rennen hier so viele Klugscheisser rum? Is ja unglaublich echt...

Portierbarkeit spielt hier doch keine Rolle, es geht ihm darum dass sich das Fenster nicht schließt, wenn das Programm beendet wird - unwahrscheinlich, dass er das beibehält im fertigen Code...

Und es interessiert doch auch nicht, ob noch 20 neue Prozesse gestartet werden..

 

[Stefan_Sch]

Breakpoint setzen oder direkt in der Konsole aufrufen -> Problem gelöst!

 

[XunnD]

Warum rennen hier so viele Klugscheisser rum? Is ja unglaublich echt...

Portierbarkeit spielt hier doch keine Rolle, es geht ihm darum dass sich das Fenster nicht schließt, wenn das Programm beendet wird - unwahrscheinlich, dass er das beibehält im fertigen Code...

Und es interessiert doch auch nicht, ob noch 20 neue Prozesse gestartet werden..

Soll ich mal klugscheißen?

Wo steht bitte, dass Portierbarkeit keine Rolle spielt?
Unwahrscheinlich heißt nicht sicher!


Also würde ich mal ganz still sein...

 

[7H3 N4C3R]

Wo steht bitte, dass Portierbarkeit keine Rolle spielt?

Nirgendwo, das hat auch niemand behauptet. Nur, dass es hier keine Rolle spielt. Also verallgemeiner das bitte nicht.

Mal ganz davon abgesehen, dass diese ganzen Unterfangen mit getch, cin.get [fehlende persönliche standardkonforme Lieblingsvariante] ebenfalls nicht portabel sind, da im Standard nirgendwo von einer Konsole geredet wird.

 

[Stefan_Sch]

cin.clear();  
cin.ignore(255, '\\n');  
cin.get();

 

[XunnD]

Nirgendwo, das hat auch niemand behauptet. Nur, dass es hier keine Rolle spielt. Also verallgemeiner das bitte nicht.

Auch hier wurde mit keinem Wort erwähnt, was die Rahmenbedingungen bezüglich Portierbarkeit sind, daher ging ich von Portierbarkeit aus, da jeder Programmierer heutzutage auch an Unix denken und nicht nur in seinem Windows-Haus wohnen sollte, auch in Zeiten von Wine & Co. ...

Sei's drum.


Ich denke da immer einen Schritt weiter - sicher ist system("pause") hier pragmatisch und einfach, aber man sollte keinem, der danach fragt, zu so einem Schritt raten, als nächstes taucht die Frage auf: "Wie kann ich die eingegebene Taste von system("pause") abfangen?"

 

[7H3 N4C3R]

Prinzipiell gebe ich dir schon recht.

Allerdings - Konsolen sind ein nicht-portables Ding. Das "Warten" auf einen Tastendruck ist immer problematisch. Insbesondere, wenn du unter LUnix eine Datei an das Programm pipest. Was passiert z.B. bei einem cin.ignore(numeric_limits<streamsize>::max), wenn ein 20 GB Bandlaufwerk hinter der Datei hängt? :-) Und, man hat keine Garantie, dass überhaupt alle Daten gepuffert sind. Außerdem kann lesen, je nach Device eine Blocking-Operation sein, was vielleicht noch schlimmer ist. Das blinde Überlesen von Input ist imho eine noch viel schlechtere Sache, als einen kleinen unportablen Hack einzubauen. (und in diesem Licht steht auch die Lösung von Stefan_Sch)

Dagegen mit system("pause") einen neuen Prozess zu starten, der einen leeren Eingabepuffer hat und garantiert das leisten kann, was man erwartet, finde ich nicht verwerflich. Solange man exakt diesen speziellen Test für erste Gehversuche machen will. Natürlich ist das generell schlecht, das will ich dann hiermit auch nochmal betonen.

Die einzig saubere Lösung ist, sowas wegzulassen - vor allem weil man mit jeder dieser Varianten die Ausgaben von automatischen Objekten in Main, von statischen Objekten die nach Ende von main zerstört werden, und von atexit Handlern nicht sieht. Das Programm muss halt einfach aus ner Konsole gestartet werden.

 

[Tumbleweed]

Das Problem war übrigens nach den ersten Antworten gelöst und man muss über solchen Firlefanz kein Buch schreiben.
Da der TE sich nicht mehr meldet, scheint es ja ohnehin nicht so wichtig gewesen zu sein und ich verweise noch mal auf meine Frage, die ich ein Stück weiter oben gestellt habe.