No one is explicitly telling you this, so I will:
What you see when you double-click the file is normal. What your IDE does (keeping the window open) is a feature to help you debug the application.
Why is this so?
Since you're developing a console application, there has to be a console for your application to display its output on. If there is none yet, a new console is created (which is the black window).
If you launch your program from inside a console (say, from cmd.exe
), it will just inherit the console of the parent without creating a new one[1].
After the last application using the console exits (which, in the first case is just your program), the console closes. You will notice this all the time for console applications that print nothing but a help text when run without parameters. If you double-click them from explorer, a black window with some text will flash and then immediately close.
Sometimes, a program that does something and them immediately closes is what you want. For example, you can call these applications from scripts.
On the other hand, your application could be interactive: waiting for user input, doing some thing, and only exiting when the user tells it to. You cannot script these applications, obviously, as you will need to have a human present at the keyboard to tell the application what to do.
Now we get to the IDE part: let's say you're developing an application of the first kind, one that does something and then immediately closes. It's not very convenient to have the screen flash and disappear every time you run it, because how can you tell if the program worked? Assuming you can tell this from the output it generates.
You could of course start a command-line window and run the application from there, but the program would execute separately from the IDE, and you would lose live debugging capabilities.
So, IDE makers came up with a feature for console applications: when you run the application directly from your IDE, they afterwards, usually waiting for a keypress. This gives you the opportunity to inspect the window with the output, to confirm that the application is working properly.
[1] Esoterica: unless you go through an application that does not inherit the console. Any console app launched by that application will not inherit the console, since the inheritance was broken by the GUI app. For example, start.exe
does this. Compare:
foo.exe (inherits the console)
start foo.exe (start.exe is a GUI app, so foo.exe is launched in a new console)