locked
Basic console problem- window doesn't open for long enough RRS feed

  • Question

  • Hi,

    I'm a beginner to C++, so my question is rather trivial. I've been trying to compile a couple of simple console win32 programs with reasonable success so far. However, whenever I run them, the console window automatically closes as soon as it runs the last command. Is there any way I can keep it running so that I can manually close it? I know there is a feature like this in Pascal, with which I'm familiar and it helps me understand if the outcome is what I expect.

    Wednesday, July 22, 2009 10:01 AM

Answers

  • Hi,

    when I was beginner, I struggled with exactly the same problem, some classmates even used to put a "getch();" at the end of program (don't do that!!!), which I consider one of the most awful workaround I ever met.

    The short answer is: Debug -> Start without Debugging (works both in Debug and Release configurations), or hit CTRL+F5 (also works in both configurations). The long answer is: do CTRL+F5 instead of F5 (the former "starts _without_ debugging", the latter launches "starts (_with_) debugging"). Note that these "with/without debugging" are totally unrelated to the "Debug" and "Release" configurations: the "start debugging / start without debugging" just decide whether you launch the program in debugger ("start debugging"), or from command prompt and wait before closing the console window until you press any key ("start without debugging"). So "start debugging" in fact means "start in debugger", that means all your breakpoints will be honored etc., i.e. you "start debugging" when you know you have problem and you have set a breakpoint and/or want to step through the code with F10/F11/Shift+F11. On the other hand, "start without debugging" in fact means "launch normally as if done by user from command prompt, i.e. do not launch in debugger", and this is designed so that the program is given a normal run as if used from command line and you can see what results it produces, and for convenience, it makes sense to stop the window in the end so you can inspect what the program output on the standard output, so the Visual Studio also does exactly that in "start without debugging.

    As I said, Debug and Release are completely unrelated (and orthogonal) to "start debugging / start without debugging", they just decide how much debug info will be present _in case_ you decide to launch them inside debugger (and how much checking the standard library will do to detect bad situations).

    Hope this helps,
    Boris
    • Edited by Boris Dušek Wednesday, July 22, 2009 11:57 AM
    • Marked as answer by wasas Wednesday, July 22, 2009 5:35 PM
    Wednesday, July 22, 2009 11:52 AM

All replies

  • Hi,

    when I was beginner, I struggled with exactly the same problem, some classmates even used to put a "getch();" at the end of program (don't do that!!!), which I consider one of the most awful workaround I ever met.

    The short answer is: Debug -> Start without Debugging (works both in Debug and Release configurations), or hit CTRL+F5 (also works in both configurations). The long answer is: do CTRL+F5 instead of F5 (the former "starts _without_ debugging", the latter launches "starts (_with_) debugging"). Note that these "with/without debugging" are totally unrelated to the "Debug" and "Release" configurations: the "start debugging / start without debugging" just decide whether you launch the program in debugger ("start debugging"), or from command prompt and wait before closing the console window until you press any key ("start without debugging"). So "start debugging" in fact means "start in debugger", that means all your breakpoints will be honored etc., i.e. you "start debugging" when you know you have problem and you have set a breakpoint and/or want to step through the code with F10/F11/Shift+F11. On the other hand, "start without debugging" in fact means "launch normally as if done by user from command prompt, i.e. do not launch in debugger", and this is designed so that the program is given a normal run as if used from command line and you can see what results it produces, and for convenience, it makes sense to stop the window in the end so you can inspect what the program output on the standard output, so the Visual Studio also does exactly that in "start without debugging.

    As I said, Debug and Release are completely unrelated (and orthogonal) to "start debugging / start without debugging", they just decide how much debug info will be present _in case_ you decide to launch them inside debugger (and how much checking the standard library will do to detect bad situations).

    Hope this helps,
    Boris
    • Edited by Boris Dušek Wednesday, July 22, 2009 11:57 AM
    • Marked as answer by wasas Wednesday, July 22, 2009 5:35 PM
    Wednesday, July 22, 2009 11:52 AM
  • Thanks a lot. This solved my problem very conveniently.
    Wednesday, July 22, 2009 5:36 PM
  • Hi,

     

    I do 'Start without Debuging' in Visual Studio 2010 RTM, but console window doesn't keep open !

    How can I solve this problem in Visual Studio 2010?

     

     

    ----

    added

    I solve the problem by setting Subsystem="/SUBSYSTEM:CONSOLE" on "linker/system" project page in C++.

    • Proposed as answer by halex2005 Thursday, May 20, 2010 7:41 AM
    Thursday, May 20, 2010 7:32 AM
  •  

    I solve the problem by setting Subsystem="/SUBSYSTEM:CONSOLE" on "linker/system" project page in C++.

    Hello,

    How do you set subsystem console? Can you please provide the steps to do it....thanks in advance...

    Saturday, June 19, 2010 8:03 PM
  • got it..thanks..good stuff
    Saturday, June 19, 2010 8:11 PM
  • If you are using visual studio 2010 (maybe 2008 also) you can just right click, go to "breakpoint" and click "insert breakpoint" at the point where your main returns. IE

    #include <iostream>
    #include <string>
    #include "input.h"

    int main()
    {

        InputFunct(std::cin);
        return (0);                    // Right click after the semicolon and insert the breakpoint here
    }

    std::istream& InputFunct( std::istream &inputStrm)
    {
        std::string input;
        while ( inputStrm >> input, !inputStrm.eof() )
        {
        }
        std::cout << input;
        inputStrm.clear(std::istream::eofbit);
        return inputStrm;
    }

    • Proposed as answer by Dream In Color Saturday, June 26, 2010 7:06 AM
    Saturday, June 26, 2010 7:05 AM
  • I, too, am an unlicked pup here. (Well, not quite unlicked, and not quite a pup: I learned FORTRAN by punching cards into a System 360...But it's been a long time.) I just got my copy of Kernighan & Ritchie, and I'm running the free download of Visual Studio 2010 for C++.

    If you want the debugger to be active, Dream In Color's suggestion to put breakpoint on the return statement (or on the closing brace) works well.

    [edit]

    I just ran across another technique:

    #include <iostream>    // Provides the "system" function we'll use
    void main()
    {
    	// Your cool code that does useful stuff
    	system("pause");  // Halts execution; shows the "Press any key to continue..." prompt
    
    }

    I'm gonna have to look into the System function; that sounds like it might do all sorts of useful things.

    [/edit]

    Boris Dušek 's CTRL+F5 solution works very well if you don't need the debugger, but you must also follow halex2005's suggestion. Here's how:

    1) Open up your project, and go to the Solution Explorer. If you're following along with me in K&R, your "Solution" will be 'hello' with 1 project under it, also 'hello' in bold.

    2. Right click on the 'hello" (or whatever your project name is.)

    3. Choose "Properties" from the context menu.

    4. Choose Configuration Properties>Linker>System.

    5. For the "Subsystem" property in the right-hand pane, click the drop-down box in the right hand column.

    6. Choose "Console (/SUBSYSTEM:CONSOLE)"

    7. Click Apply, wait for it to finish doing whatever it does, then click OK. (If "Apply" is grayed out, choose some other subsystem option, click Apply, then go back and apply the console option. My experience is that OK by itself won't work.)

    Now do Boris' CTRL-F5, wait for your program to compile and link, find the console window under all the other junk on your desktop, and read your program's output, followed by the beloved "Press any key to continue...." prompt.

    Again, CTRL-F5 and the subsystem hints work together; they are not separate options.

    Annoyingly, there is no hint that the "subsystem" option will do this. Its description, which cannot be copied (I HATE HATE HATE text that cannot be selected and copied. PFUI!) says:"The /SUBSYSTEM option tells the operating system how to run the .exe file. The choice of subsystem affects the entry point symbol (or entry point function) that the linker will choose." OOOkay, I guess... But why is this not in any of the help files I could find, or in any of the walk throughs? Why isn't this the default setting? Why is VS getting in my way, instead of helping me along?

    • Proposed as answer by SA PRE Saturday, December 11, 2010 8:00 PM
    Thursday, September 2, 2010 6:29 AM
  • @DJMooreTX - You ROCK! Thanks for the /SUBSYSTEM nfo! =)

    Wednesday, November 17, 2010 7:00 AM
  • You are the man. You are the only person on the web who gave clear instruction. thank you
    Friday, December 3, 2010 10:34 PM