system("pause"); - Why is it wrong?

Viewed 366945

Here's a question that I don't quite understand:

The command, system("pause"); is taught to new programmers as a way to pause a program and wait for a keyboard input to continue. However, it seems to be frowned on by many veteran programmers as something that should not be done in varying degrees.

Some people say it is fine to use. Some say it is only to be used when you are locked in your room and no one is watching. Some say that they will personally come to your house and kill you if you use it.

I, myself am a new programmer with no formal programming training. I use it because I was taught to use it. What I don't understand is that if it is not something to be used, then why was I taught to use it? Or, on the flip side, is it really not that bad after all?

What are your thoughts on this subject?

15 Answers

It's frowned upon because it's a platform-specific hack that has nothing to do with actually learning programming, but instead to get around a feature of the IDE/OS - the console window launched from Visual Studio closes when the program has finished execution, and so the new user doesn't get to see the output of his new program.

Bodging in System("pause") runs the Windows command-line "pause" command and waits for that to terminate before it continues execution of the program - the console window stays open so you can read the output.

A better idea would be to put a breakpoint at the end and debug it, but that again has problems.

It's slow. It's platform dependent. It's insecure.

First: What it does. Calling "system" is literally like typing a command into the windows command prompt. There is a ton of setup and teardown for your application to make such a call - and the overhead is simply ridiculous.

What if a program called "pause" was placed into the user's PATH? Just calling system("pause") only guarantees that a program called "pause" is executed (hope that you don't have your executable named "pause"!)

Simply write your own "Pause()" function that uses _getch. OK, sure, _getch is platform dependent as well (note: it's defined in "conio.h") - but it's much nicer than system() if you are developing on Windows and it has the same effect (though it is your responsibility to provide the text with cout or so).

Basically: why introduce so many potential problems when you can simply add two lines of code and one include and get a much more flexible mechanism?

  • slow: it has to jump through lots of unnecessary Windows code and a separate program for a simple operation
  • not portable: dependent on the pause command
  • not good style: making a system call should only be done when really necessary
  • more typing: system("pause") is longer than getchar()

a simple getchar() should do just fine.

In summary, it has to pause the programs execution and make a system call and allocate unnecessary resources when you could be using something as simple as cin.get(). People use System("PAUSE") because they want the program to wait until they hit enter to they can see their output. If you want a program to wait for input, there are built in functions for that which are also cross platform and less demanding.

Further explanation in this article.

Because it is not portable.
pause command is a windows / dos only program, so this your code won't run on linux/macOS. Moreover, system is not generally regarded as a very good way to call another program - it is usually better to use CreateProcess or fork or something similar.

system("pause");  

is wrong because it's part of Windows API and so it won't work in other operation systems.

You should try to use just objects from C++ standard library. A better solution will be to write:

cin.get();
return 0;

But it will also cause problems if you have other cins in your code. Because after each cin, you'll tap an Enter or \n which is a white space character. cin ignores this character and leaves it in the buffer zone but cin.get(), gets this remained character. So the control of the program reaches the line return 0 and the console gets closed before letting you see the results.
To solve this, we write the code as follows:

cin.ignore();  
cin.get();  
return 0;

Next to the arguments provided already (insecurity, slowness, non-portability, ...) there's yet another point missing:

If you are writing production tools of whatever kind then one should keep in mind:

  • Keeping an application window open is not the task of the application! Trying to do so by whatever means (system("pause");, getchar();, getch() or whatever else) is wrong by principle.
  • The application waiting for user input prevents it from being runable in any kind of scripting (bash script, windows batch file, ...), which is a pretty common use case – who should provide the user input there?

These problems would already start if your teacher tried to automise testing your programme with different inputs in his own script (obviously it doesn't...)!

Now if you are just playing around with any kind of testing code that you'll throw away anyway without having been seen by anywhere else (including your teacher) – who should care? Problem then, though, is that you will get used to such practices and will tend to use them even in places where you shouldn't. So best don't get used to right from the start...

It doesn't matter.

Adding a system("pause") or getchar() or std::cin.get() or whatever else you like at the end of a console program is there solely for the benefit of the programmer during development. The only purpose of such a line is to ensure that the console won't close before the programmer can view it, when executing the program from inside some IDE that likes to close the console when done executing.

That line will never make it to the production code executable, because why would anyone add "press any key to continue" at the end of a program executed from a console? That's not how sane console program UI works and they never have.

In general, using system() is bad practice but that's another story.

Related