How to make console apps keep appearing with only return 0?

Started by
6 comments, last by Jouei 16 years, 9 months ago
I don't get how people do it. But their compilers can just keep the program running with just a return 0. Allow me to explain. By the way, my IDE is VS2005.

#include <iostream> 
using namespace std; 

int main(int argc, char *argv[])
{
    cout << "Hello, World! \n"; 
    cin.get();  //I have to add this to keep the app appearing
    return 0;   //Some people only need return 0, and not the cin.get() part, why?  
}

Ok, so now you get my question. How can I make my console app appear without flashing for a sec then quitting, but using only return 0, and not including the cin.get() part of it? Remember, Visual Studio 2005 Professional.
Advertisement
The typical approach is to place a breakpoint on the last line of your program (typically the return 0; if you have one, although usually it isn't necessary). Press F9 to set or remove a breakpoint, and Ctrl+F5 to exit from a program once it has reached a breakpoint.
I believe that a simple system("pause"); should solve that (under Windows).

EDIT:
A Sleep(1000); would solve it too, or a loop, like while(running){ doStuff(); }...

[Edited by - blueapple on July 7, 2007 5:48:20 AM]
Check out my devlog.
I assume that by "keep appearing" you mean "continue to appear".

The console window that pops up is actually nothing to do with your program. It's created to give a context in which your program runs; your program just takes input from a "standard input" and feeds it to "standard output"; your operating system does the rest (i.e. connecting stuff typed at the keyboard to your program's input, and translating the output into pixels on the screen, taking into account, of course, all the other windows that are being drawn at the time).

Some IDEs will generate a window that simply lasts for as long as the program is up and running; when your program finishes, the window isn't needed any more, so it's just removed. Of course, when a program is fully developed, it will normally run outside of any IDE. If you just double-click something, Windows will again only give the program a console window for as long as it's running. To get around this, you need to *run the program properly*.

One way under Windows is to open a 'permanent' console window - i.e. by running 'cmd' from Start->Run - and executing the program from there (with the relevant DOS commands - i.e., use 'cd' to get to the folder where the program is located, and then just type the program name). You could also supply arguments (e.g. 'myprogram.exe foo bar baz'); these will be "picked up" by the parameters of main(), if you declared it to have them (remember that you can have either int main() or int main(int, char**), where those parameters are traditionally named 'argc' and argv'). The int is set to the number of things typed on the command line (including the program name itself), and the char** is an array of that length of char*'s, each of which points at one of those things.

You could also make a batch script to run the program and then run the 'pause' Windows program (which displays "Press any key to continue...", waits for a keypress - using system specific stuff, not std::cin - and then exits). Then, when you double-click the batch file, a window pops up, your program runs in it, then the pause program runs; when the user hits a key, *then* the window disappears, because the *script* (which is what "owns" the window) is finished.
Can someone explain to me why throwing a cin.get at the end of your program isn't cool? I mean, as long as you understand that it's an IDE thing rather than a console thing, where's the problem?
[ search: google ][ programming: msdn | boost | opengl ][ languages: nihongo ]
Quote:Original post by _goat
Can someone explain to me why throwing a cin.get at the end of your program isn't cool? I mean, as long as you understand that it's an IDE thing rather than a console thing, where's the problem?


Because you're not making an application to run in IDE. See the console advice.

Other than that, there's "Start without debugging" or Ctrl-F5 in "Debug" menu.

But again, use separate console window and run from there.
The truth is, I can't think of a single useful console application that should pause after the program exits. Except for a few very simple programs when you're first starting out, they serve no good purpose. There are two possibilities: you want user interaction or you don't. If you don't want user input for, say an image converter program in a console application. You can call it like so:
filecnvt -o input.bmp -bmp output.jpg -jpeg

That is, of the form: program [options] inputFilename [filetype] outputFilename [filetype]. The only user interaction you might want in this case is to ask 'would you like to overwrite outputFilename? y/n' which you can avoid by specifying that -o (which in this case would mean overwrite without asking). The user of the program might want to run the program on a bunch of files in which case they could just write a batch program to automate the task.

The other possibility is you want to have a program that Does involve user input. Say a banking program like back in the day. In this case, you'll want to keep the program open until the user wants to quit. Because the program is looping the data stays on screen until the user leaves. And if the user left, why would the program stay open? Any information the user wanted they could have asked for explicitely.

So even if your simple programs do one thing and immediately exit, it's bad to get in the habbit of stopping the code from exiting artificially. If you want your friends to run your program without entering the command line just make a batch(.bat) file with:
programname.exe
pause

in it and have them double click that instead of double clicking programname.exe. Or you could write programs that loop until the user specifies that they want to leave. (dumb for simple 'hello world' apps, smart for many other apps).

C++: A Dialog | C++0x Features: Part1 (lambdas, auto, static_assert) , Part 2 (rvalue references) , Part 3 (decltype) | Write Games | Fix Your Timestep!

if i am not mistake the only time the window will automaticly close for a console application is when you debug it if you run it without debugging it should wait for a users return the exit at least when run through the ide.

Regards Jouei.

This topic is closed to new replies.

Advertisement