@ Bazzy:
Good point: it's not cross-platform.
Bad context: you don't need it, or a substitute for it, to begin with.

Just an off-topic:

I use this code, and I never thought how unsecure it is:

Any suggestions/comments?

Isn't the security paranoia getting out of proportions? What's next? Don't run the compiler or any other program from the command line because there could be a virus installed with the same name? I guess it's worse on Windows because it doesn't require the prefix ./ for programs in the current working directory.

Bazzy, if you really wanted to see it in linux try system("read");. Of course, who needs to pause when you're already in a terminal...

I'm in the won't complain or scold about using system camp. It's not ideal for production code, much like the many, many other horrible lines of code that are written every day for production systems...

If we work together and I'm doing your code review, I'd comment on it. On a forum, primarily focused on homework and hobby projects, I'd let it go.

That's not how multitasking works on modern OSes. When you request input or output (from anything), the scheduler makes a note of it, sends the request to the right place, and then puts the process to sleep. It switches to the next process immediately. The program only gets woken up when (1) the I/O is ready and (2) it's the process's turn to run. The idea is that the CPU should never be idle. In practice, it often is (look at the "System Idle Process" on Windows), but that's only when it has nothing else to do.

If you don't press a key for say... a minute, then assuming the scheduler gives 1/60th of a second to each proccess (and assuming you have 60 processes running) you would be wasting a second of CPU time, with which your other 59 processes could do a lot of computing.


As for system("pause");, why does this argument keep coming up? There is an easy alternative that is platform independent and more secure. And why do you ever even need to pause an application? No one starts a console application by clicking on an icon (wget, telnet, etc.), so the best alternative is to use it like people using your application will: running it from a shell.

@moorecm
I completely agree, I'd wager most of us have been guilty of this or similar method to keep console open (my old favorite was _getch()).

@BHXSpecter
I think (please correct me if I'm wrong) the correct method in windows is ShellExecute() and on linux is probably one of the exec() functions.

@ascii,
The process wouldn't be given another timeslice until its I/O was ready, so that wasted second wouldn't happen. It would be as if the process wasn't there.

This is all assuming the OS uses asynchronous I/O, of course, but unless it's DOS, it should.

When you signal the OS to wait on an I/O, your process doesn't get any timeslices until I/O is ready -- the OS gets timeslices to route I/O.

@Peter87
PressAnyKey() is a function you write or link yourself. If you want, one of my articles will give you a working copy of it.

@Catfish2
So, you can say any nonsense crap you want, with all your lack in education about secure computing, and insinuate moronics on whomever disagrees with you, but boo hoo anyone who knows better and points out that you are full of it? Thanks for showing your true colors.

Bye now.

So, you can say any nonsense crap you want, with all your lack in education about secure computing, and insinuate moronics on whomever disagrees with you, but boo hoo anyone who knows better and points out that you are full of it? Thanks for showing your true colors.

Look everybody, Duoas thinks he's won an argument, again.

Also...

@Peter87 PressAnyKey() is a function you write or link yourself. If you want, one of my articles will give you a working copy of it.

http://cplusplus.com/articles/iw6AC542/
It even has two 30+ line platform-specific versions, perfect for newbies.

Of course, the piece de resistance is (as expected):

Teaching people to use the system function for anything is irresponsible. It's slow, unsafe and platform-dependent. No, those things don't matter so much outside of production code, but why teach bad habits in the first place? Why not get used to doing things the right way from the start? When there are much better methods for accomplishing the same thing which require no extra effort, it just seems stupid to teach people to do it the wrong way and then unteach them when (if) they get into the real world.

You can do this:


Ideally, you'd not do this either because your console application shouldn't pause in the first place, but if you really do need it, that's probably the best way to do it.

Also, you being arrogant (perceived or actually) is what started this in the first place, so you're really just making it worse at this point.

No, those things don't matter so much outside of production code, but why teach bad habits in the first place? Why not get used to doing things the right way from the start?

How come using system("PAUSE"); is a worse habit than misusing ignore()? Or are you genuinely afraid that newbies can grow to abuse system() calls and keep their jobs?

If you want to teach good habits, then I think you, Duoas and I agree on the same thing: console programs should be run naturally from the console.

If you want to promote tricks and hackery, that's your personal endeavor and please don't call me arrogant if I won't accompany you.

Using and misusing system() are mutually inclusive.

Catfish2 wrote:
Or are you genuinely afraid that newbies can grow to abuse system() calls and keep their jobs?

Tell me exactly where I said that. Of course, you can't, because I didn't say it. Don't put words in my mouth.

Catfish2 wrote:
console programs should be run naturally from the console.

Of course, but don't try to move the goalposts now. This wasn't about whether running it from the console or running it from the file manager is better, this started because you advocated leaving people to it when they use system() instead of one of the better ways. No, std::istream::ignore() is not perfect, no-one said it was; but it's better than using system().

Catfish2 wrote:
If you want to promote tricks and hackery, that's your personal endeavor and please don't call me arrogant if I won't accompany you.

Again, don't put words in my mouth. I didn't call you arrogant for that reason (technically I didn't call you arrogant at all, I said you were being perceived as such).

Catfish2 wrote:
It’s a pet peeve that makes them feel superior to you.

Do you not see the irony in that statement? Do you not see how that could be perceived as arrogance?

The process wouldn't be given another timeslice until its I/O was ready, so that wasted second wouldn't happen. It would be as if the process wasn't there.

When you signal the OS to wait on an I/O, your process doesn't get any timeslices until I/O is ready -- the OS gets timeslices to route I/O.

Woops, I was wrong.


As for this thread, it should end now. Clearly people are beyond attacking other peoples opinions and are actually attacking them personally. So... stop?

If you see some beginner doing something that is bad practice in their homework or hobby project, like our favorite example of calls to system(), let them know it's not really a big deal in this situation but make sure you tell them it's bad practice and explain why. If they want to do it the right way after that, good for them, otherwise as long as they understand why it's bad they should be inclined to do things the right way when the time comes that they should.

@ascii,
Yeah, I'll leave it there.

If you're interested in the OS stuff, read Operating Systems: Design and Implementation by Andrew Tanenbaum & Albert Woodhull, it's excellent. It's kind of expensive, but I'm sure you can find a "free version" on a certain "the sailor port" if you are so inclined.

@xander337,
That's probably the most reasonable solution.

Using and misusing system() are mutually inclusive.

Security, performance and resources issues. Which aren't beginner topics anyway.

this started because you advocated leaving people to it when they use system() instead of one of the better ways.

First and foremost I advocated that they should run their programs in the console. I do not consider that ignore() is the way to go, and just because you do prefer ignore() to system("PAUSE");, it doesn't make the former the better/right way, and also I'm getting tired of that meaningless cliche without a context.

Lastly, I do honestly apologize for strawman attacks.

Who said that system("pause"); is insecure?

D:\zzz>dir Volume in drive D has no label. Volume Serial Number is E4CA-D020 Directory of D:\zzz 2012.06.26 20:04 <DIR> . 2012.06.26 20:04 <DIR> .. 2012.06.26 20:03 651.264 pause.exe 1 File(s) 651.264 bytes 2 Dir(s) 5.378.670.592 bytes free D:\zzz>pause Press any key to continue . . . D:\zzz>pause.exe pause.exe started. D:\zzz>

Telling someone who doesn't know why their hello world program isn't working, that they should be running their programs in the console, is not going to be helpful in my opinion.




I think that if someone is going to be telling a beginner to use this to pause their program, they should at least give a thorough explanation of what they're writing. I think otherwise this advice can start a bad habit of copying and pasting snippets of code they don't understand to solve they're problems.

Maybe it would be appropriate to tell them to use a break point?

@Null,
I seriously doubt cmd.exe ever uses the system() function.

iseeplusplus wrote:
I think that if someone is going to be telling a beginner to use this to pause their program, they should at least give a thorough explanation of what they're writing. I think otherwise this advice can start a bad habit of copying and pasting snippets of code they don't understand to solve they're problems.

Yeah, that's a good point. It isn't difficult to explain, though: effectively, it tells the user to press ENTER (unless 'false' is passed for 'prompt') and then waits until they do.

Catfish2 wrote:
Security, performance and resources issues. Which aren't beginner topics anyway.

No, but they don't have to be explained in detail. You can literally just say "it's not safe, it's slow and it doesn't work on everyone's system". If someone asks for more detail you can give it - "it could run a malicious program with the same name, it requires the operating system to search for, load and run another executable instead of just waiting for input, and the 'pause' command generally only exists on Windows and DOS, and on other systems may do something completely different than what you expect".

First and foremost I advocated that they should run their programs in the console. I do not consider that ignore() is the way to go, and just because you do prefer ignore() to system("PAUSE");, it doesn't make the former the better/right way, and also I'm getting tired of that meaningless cliche without a context.

But ignore is better, not just because I say it is, but because it really is better in every way, with the possible exception of obviousness. It is well-documented what ignore() does. It is required to behave (or act as if it behaves) the same way on any system which has a compliant C++ library. It doesn't require you to assume anything except that the implementation you are using complies with the standard, which is a fair assumption to make, because without a compliant standard library implementation there's hardly anything useful you can do in C++ because there are no built-in I/O facilities.

system("pause"), on the other hand, requires you to assume (1) that an executable called 'pause' exists, (2) that the OS can find it, (3) that the OS can load & run it, and (4) that it pauses the program and waits for input. And that is on top of the other issues inherent to using system() in the first place. There is literally no reason to teach it. Yes, people should run their programs in the console or use an IDE that pauses the console for them, but they don't always do that. The next best thing is to just use ignore().

Lastly, I do honestly apologize for strawman attacks.

That's okay.