Какова Лучшая практика для Борьбы с Консольной Проблемой Закрытия?

When I'm using Visual Studio and I don't need debugging I just run it using Ctrl+F5 keystroke – and it prevents console from closing.

cin is grossly inelegant but easy for the forgetful to derive:

{
  char c;
  std::cin >> c;
}

That holds the window open until you type a character /* edit */ and hit 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 &).

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.

Since you always run in the debugger, set a breakpoint on the return statement from main().

The debugger is your best friend, learn (and learn early) to use it to your advantage at every opportunity.

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 PAUSE cmd.exe command will ask to user to press any key.

I tend to use system("PAUSE"); which gives you a

Press any key to continue . . .

message.

Я использую:

cin.get()

Я слышал, что это дешевле, чем системное ("ПАУЗА"), и оно также работает в системах POSIX. Там есть отличная ссылка , которая подробно описывает это.

Не поддавайтесь искушению сделать что-нибудь. Программы командной строки с хорошим поведением завершаются, когда завершают работу, сообщая о состоянии с помощью своего кода выхода. Это позволяет им быть «хорошими гражданами» в автоматизированных средах, готовыми к сценариям. Даже в интерактивной среде, зачем заставлять пользователя делать дополнительное нажатие клавиши только из-за вашей среды отладки?

Если вы запустите, вместо отладки Visual Studio откроет окна консоли, которые приостанавливаются после выхода из приложения, чтобы вы все еще могли просматривать вывод. Я не знаю, почему поведение отличается при отладке, возможно, потому, что у вас есть точки останова, поэтому, если вы хотите увидеть результат на разных этапах, вы можете разместить точки останова после соответствующих операторов вывода или в конце main или включить различные опции «останавливать при выдаче исключения».

Какой бы ни была причина, я никогда не чувствовал себя обязанным нарушать поведение моего приложения только для улучшения моего опыта отладки.

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.

Call this function before you return at the end of main:

void onEnd()
{
    printf("Press any key to exit...");
    _getch();
}