windows 解决控制台关闭问题的最佳实践是什么？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/1173208/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
What is the Best Practice for Combating the Console Closing Issue?
提问by Lonestar
After compiling console programs the console window closes immediately after running. What is the best practice for keeping it open? I've searched google loads, I'm used to codeblocks where you don't have to worry about it, but, I want to mess around with Visual Studio a bit and with VS, my console closes. All over the interwebz there are several different ways to keep it open, however, I've read that most of them are bad coding techniques. What is everyones preferred method?
编译控制台程序后，控制台窗口在运行后立即关闭。保持开放的最佳做法是什么？我已经搜索了 google 负载，我已经习惯了代码块，您不必担心它，但是，我想稍微使用 Visual Studio 和 VS，我的控制台关闭了。在整个interwebz 上，有几种不同的方法可以保持它的开放性，但是，我读到其中大多数都是糟糕的编码技术。大家最喜欢的方法是什么？
回答by Regent
When I'm using Visual Studio and I don't need debugging I just run it using Ctrl+F5keystroke – and it prevents console from closing.
当我使用 Visual Studio 并且不需要调试时，我只需使用Ctrl+ F5keystroke运行它- 它可以防止控制台关闭。
回答by Sam Harwell
Since you always run in the debugger, set a breakpoint on the return statement from main().
由于您始终在调试器中运行，因此在来自main().
The debugger is your best friend, learn (and learn early) to use it to your advantage at every opportunity.
调试器是您最好的朋友，学习（并尽早学习）以利用它在每一个机会中为您带来好处。
回答by erjiang
Run your program in a console, which would be the expected way of running a console program ...
在控制台中运行您的程序，这将是运行控制台程序的预期方式......
Alternatively, you can make a little batch file to execute your program that would have:
或者，您可以制作一个小批处理文件来执行您的程序，该文件将具有：
REM batch file to launch program
yourprogram.exe
PAUSE
and the PAUSEcmd.exe command will ask to user to press any key.
并且PAUSEcmd.exe 命令将要求用户按任意键。
回答by Thomas L Holaday
cinis grossly inelegant but easy for the forgetful to derive:
cin非常不雅观，但对于健忘的人来说很容易得出：
{
char c;
std::cin >> c;
}
That holds the window open until you type a character /* edit */ and hit enter.
这会使窗口保持打开状态，直到您键入字符 /* edit */ 并按 Enter 键。
std::cin.get()will close the window the moment you type a character, which, depending on how easily you become habituated, runs a marginally greater risk of "whoops, I wish I hadn't closed that!" than the two-keystroke operator>>(istream &).
std::cin.get()将在您键入字符的那一刻关闭窗口，根据您习惯的容易程度，该窗口会冒“哎呀，我希望我没有关闭那个！”的风险略高一些。比两次击键operator>>(istream &)。
Both differ from a system("pause")in that they return in a program-accessible way the value of the character you typed, so, if as not infrequently happens, one kludge leads to another, you can write a switch statement based on what you typed to (for example) exit immediately, write some values to a log, run it again, etc.
两者都与 a 不同system("pause")，因为它们以程序可访问的方式返回您键入的字符的值，因此，如果经常发生，一个kludge 导致另一个，您可以根据您键入的内容编写 switch 语句（对于例如）立即退出，将一些值写入日志，再次运行，等等。
回答by irh
I tend to use system("PAUSE");which gives you a
我倾向于使用system("PAUSE");它给你一个
Press any key to continue . . .
Press any key to continue . . .
message.
信息。
回答by Steve
回答by CB Bailey
Resist the temptation to do anything. Well behaved command line programs exit when they've finished running reporting a status via their exit code. This enables them to be scriptable and 'good citizens' in automated environments. Even in an interactive environment, why force the user to make an extra key press just because of your debugging environment?
抵制做任何事情的诱惑。表现良好的命令行程序在通过退出代码完成运行报告状态后退出。这使他们能够在自动化环境中编写脚本并成为“好公民”。即使在交互式环境中，为什么仅仅因为您的调试环境而强迫用户进行额外的按键操作？
If you run, rather than debug then Visual Studio will open a console windows that pauses after your application exits so that you can still view the output. I don't know why the behaviour is different when you debug, perhaps because you have breakpoints available so if you want to see the output at various stages you can place breakpoints after the relevant output statements, or at the end of mainor enable various 'stop on exception throw' options.
如果您运行，而不是调试，那么 Visual Studio 将打开一个控制台窗口，该窗口在您的应用程序退出后暂停，以便您仍然可以查看输出。我不知道为什么调试时行为会有所不同，也许是因为您有可用的断点，所以如果您想查看各个阶段的输出，您可以在相关输出语句之后放置断点，或者在结束main或启用各种 '停止异常抛出'选项。
Whatever the reason, I've never felt compelled to compromise the behaviour of my application just to enhance my debugging experience.
不管是什么原因，我从来没有觉得有必要为了增强我的调试体验而妥协我的应用程序的行为。
回答by Reed Copsey
A very common one is to just put in code to read a key from the console after your main application code closes. The keystroke read in just gets thrown away, but it holds the console open.
一个非常常见的方法是在主应用程序代码关闭后，只需放入代码即可从控制台读取密钥。读入的击键会被丢弃，但它使控制台保持打开状态。
It's not pretty, necessarily - but I often do this wrapped in a debug define, so during debugging, the console is held open. During release, I'm usually not running inside VS, and when run from a command line, this is no longer an issue.
它不一定漂亮 - 但我经常在调试定义中进行此操作，因此在调试期间，控制台保持打开状态。在发布期间，我通常不在 VS 中运行，当从命令行运行时，这不再是问题。
回答by evadeflow
The "don't do that" responses in this thread may seem curt, but they're fairly sensible. I happened across this question because I'm debugging a gtest suite that used to run fine, but now crashes mysteriously when launched. When run from the console, it pops up a dialog saying "blah.exe has stopped working"; but, when run from the debugger, the console pops up momentarily, vanishes, and the program exits with 0 status.
这个帖子中的“不要那样做”的回答可能看起来很生硬，但它们是相当明智的。我遇到了这个问题，因为我正在调试一个曾经运行良好的 gtest 套件，但现在在启动时神秘地崩溃了。从控制台运行时，会弹出一个对话框，提示“blah.exe 已停止工作”；但是，当从调试器运行时，控制台会立即弹出、消失，并且程序以 0 状态退出。
I should have been thinking about how odd this difference in behavior was, but instead I was like: "Aw, man---I gotta make that console window stay up so I can see what it says." Right?
我本应该考虑这种行为上的差异有多奇怪，但我却想：“噢，伙计——我得让控制台窗口一直亮着，这样我才能看到它说的是什么。” 对？
It turns out that the machine I'm working on (a colleague of mine's) had the 'Command Arguments' for the debugger set to '--gtest_filter=*testMsg*'. I noticed this right away, too, but it never occurred to me that all the tests matching the filter had been renamed in a recent commit. So, when launched from the debugger, gtest wasn't finding any tests to run and was simply exiting. Another 90 minutes of my life I'll never get back. (-_-) I could have ditched this tar baby a lot sooner if my knee-jerk reaction hadn't been to think I needed that console window to stay open in order to solve the problem...
事实证明，我正在使用的机器（我的一个同事）将调试器的“命令参数”设置为“--gtest_filter=*testMsg*”。我也立即注意到了这一点，但我从未想过所有与过滤器匹配的测试都已在最近的提交中重命名。因此，当从调试器启动时，gtest 没有找到任何要运行的测试，只是退出。我生命中的另外 90 分钟我再也回不去了。(-_-) 如果我的下意识反应不是认为我需要让控制台窗口保持打开状态才能解决问题，我本可以更早地放弃这个焦油宝贝...
回答by DeusAduro
Call this function before you return at the end of main:
在 main 末尾返回之前调用此函数：
void onEnd()
{
printf("Press any key to exit...");
_getch();
}
