system("PAUSE");
Blue_Hat
I was told by a friend that it is not appropriate to use it when writing
programmes, he never explained why.
I'm a beginner looking to teach myself in preparation for the
Programming Diploma I want to get. I have taken on C++ PHP and
Javascript because they are included in the curriculum and I actually
develop websites as a hobby. I want to make the move into systems
programming but I am almost too frustrated to continue. I keep hearing
different stuff from different people!
Helge Kruse
But PAUSE is not a process that can be started with system() but a command
that is performed by the command line prompt (cmd.exe). Try something like
this:
system("cmd /c PAUSE");
/Helge
"Blue_Hat" <blue...@hackershaven.com.jm> wrote in message
news:h22nmh$jr3$1...@aioe.org...
Blue_Hat
Thanks, that works the same way the system ("PAUSE");
So, is the use of it a bad practice?
Richard Heathfield
> PAUSE seems to be a Windows command.
That's one thing it can be.
> So it's not really a C++ question.
Agreed.
> But PAUSE is not a process that can be started with
> system() but a command that is performed by the command line
> prompt (cmd.exe).
Er, so what? system("PAUSE") works just fine, in the sense that it
will execute the PAUSE command, if there is one.
> Try something like this:
>
> system("cmd /c PAUSE");
I don't see what difference that would make.
<snip>
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Forged article? See
http://www.cpax.org.uk/prg/usenet/comp.lang.c/msgauth.php
"Usenet is a strange place" - dmr 29 July 1999
R. Scott Mellow
The use of "system()" ties you to a specific platform/command shell. The
string you pass (in your example "PAUSE") is something that may be
meaningful to one shell but gibberish to another.
C++ is designed to be platform independent so that programs can be
written to work on a wide variety of computers and operating systems.
All that needs to be done is to compile the program with an
implementation for that particular system. Code changes, if required at
all, should be minimal. This is known as portability.
When learning the language portability is not a primary concern but it
is important to understand the concept so you don't fall into the trap
of thinking that something like system("PAUSE") is part of C++. Yes, the
"system" function is provided by C++ but its use is, as I've said,
inherently non-portable.
--
Randy
Richard Heathfield
> What's so wrong with using system("PAUSE");
> I was told by a friend that it is not appropriate to use it when
> writing programmes, he never explained why.
Observe:
$ cat foo.c
#include <stdlib.h>
int main(void)
{
system("PAUSE");
return 0;
}
$ make
gcc -W -Wall -ansi -pedantic -Wformat-nonliteral -Wcast-align
-Wpointer-arith -Wbad-function-cast -Wmissing-prototypes
-Wstrict-prototypes -Wmissing-declarations -Winline -Wundef
-Wnested-externs -Wcast-qual -Wshadow -Wconversion -Wwrite-strings
-ffloat-store -O2 -fno-builtin -g -pg -c -o foo.o foo.c
gcc -W -Wall -ansi -pedantic -Wformat-nonliteral -Wcast-align
-Wpointer-arith -Wbad-function-cast -Wmissing-prototypes
-Wstrict-prototypes -Wmissing-declarations -Winline -Wundef
-Wnested-externs -Wcast-qual -Wshadow -Wconversion -Wwrite-strings
-ffloat-store -O2 -fno-builtin -g -pg -o foo foo.o -lm -lncurses
-lpcl
$ ./foo
sh: PAUSE: command not found
So much for that idea, eh?
Consider why you want your program to pause. If it's because you
want the reader to have time to read the text on a console, why not
do it like this?
#include <stdio.h>
void pause(void)
{
int ch = 0;
puts("Press ENTER to continue");
while((ch = getchar()) != '\n') && ch != EOF)
{
continue;
}
}
int main(void)
{
pause();
return 0;
}
Because I hate iostreams with a vengeance, translation into C++ is
left as a tedious exercise for the reader.
Keith Thompson
> What's so wrong with using system("PAUSE");
> I was told by a friend that it is not appropriate to use it when
> writing programmes, he never explained why.
First, it's not portable; it will only work on Windows systems. Well,
mostly; it could also work on non-Windows systems where a "PAUSE"
command happens to be available.
Second, the purpose of using system("PAUSE") (presumably at the end of
your program) is to prevent the system from closing the window in
which your program is running. On some systems, the normal way to
execute a program is from a command prompt (shell); in that kind of
environment, the window won't vanish when the program completes
anyway, and the system("PAUSE") is pointless. Even on Windows, you
can run a program by typing its name at a command prompt rather than
by clicking on an icon. And I think most Windows IDEs have an option
to keep a program's window open after the program terminates.
Portability is generally a good thing, but it's not an absolute
requirement unless you want it to be. If your program will
only ever be run on a Windows system, and only by a method where
the output window will vanish when the program terminates, then
system("PAUSE") probably makes sense; there are more portable
ways to achieve the same effect, but it's not a big deal.
If you want bells and whistles, you might have your program
conditionally wait for user input, perhaps controlled by a
command-line argument.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Kaz Kylheku
> What's so wrong with using system("PAUSE");
It's dumb. You're launching a whole other program, by means of a command
interpreter, just to wait for a line of input to from the console, instead of
using your I/O library.
Keith Thompson
So what? There's no portable way to do what the PAUSE command does
anyway (it waits for a single character input, without waiting for
a new-line). If that's what you want to do, then system("PAUSE") is
certainly an easier way to do it than using whatever system-specific
libraries are necessary to reinvent that particular wheel.
There are certainly some very good reasons not to use
system("PAUSE"), but I don't think the trivial overhead of "launching
a whole other program" is one of them.
Jerry Coffin
[ ... ]
> So what? There's no portable way to do what the PAUSE command does
> anyway (it waits for a single character input, without waiting for
> a new-line). If that's what you want to do, then system("PAUSE") is
> certainly an easier way to do it than using whatever system-specific
> libraries are necessary to reinvent that particular wheel.
Rather the contrary: giving any assurance that it will work correctly
(e.g. will actually find 'pause.exe' to execute) becomes fairly
difficult. On the other hand, at least under Windows (i.e. where
you'd have some expectation it might work as-is) the system-specific
code looks like: 'getch();'
With most UNIX systems, the same will work with the right header(s)
and library linked.
If it was my code, I'd probably put something like 'pause();' in the
mainstream of the code, and implement that (and other such functions)
in a file specific to each system:
// win_interface.cpp:
#include <conio.h>
void pause() { getch(); }
// unix_interface.cpp:
#include <curses.h>
void pause() { getch(); }
Obviously, _these_ could be merged into a single file with an #ifdef
to pick the header to include. Given the amount of code that's really
likely to be shared, system-specific files are usually justified
though.
--
Later,
Jerry.
Richard Heathfield
> In article <ln4ou2o...@nuthaus.mib.org>, ks...@mib.org says...
>
> [ ... ]
>
>> So what? There's no portable way to do what the PAUSE command
>> does anyway (it waits for a single character input, without
>> waiting for
>> a new-line). If that's what you want to do, then system("PAUSE")
>> is certainly an easier way to do it than using whatever
>> system-specific libraries are necessary to reinvent that
>> particular wheel.
>
> Rather the contrary: giving any assurance that it will work
> correctly (e.g. will actually find 'pause.exe' to execute) becomes
> fairly difficult.
Extremely difficult, unless you've written a pause.exe yourself or
bought/found one from somewhere. Microsoft's PAUSE command is an
*internal* command, which is part of the command processor. There
is no pause.exe anywhere.
<snip>
stan
> Helge Kruse said:
<snip>
> Er, so what? system("PAUSE") works just fine, in the sense that it
> will execute the PAUSE command, if there is one.
>
>> Try something like this:
>>
>> system("cmd /c PAUSE");
>
> I don't see what difference that would make.
I don't disagree with you Richard, but it does make the code even LESS
portable.
Richard Heathfield
I don't see how it makes a significant difference. Calling system()
is already enough to blow away any vestiges of portability. How you
call it pales in comparison.
Kaz Kylheku
> PAUSE seems to be a Windows command. So it's not really a C++ question.
> But PAUSE is not a process that can be started with system() but a command
From the C99 standard:
7.20.4.6 The system function
Synopsis
1 #include <stdlib.h>
int system(const char *string);
Description
2 If string is a null pointer, the system function determines whether the
host environment has a command processor. If string is not a null pointer,
the system function passes the string pointed to by string to that command
processor to be executed in a manner which the implementation shall
document; this might then cause the program calling system to behave in a
non-conforming manner or to terminate.
See, system is intended to be an interface to a command processor, rather than
to a lower-level process spawning utility. If a system only has a
process-spawning functionality with no command processor, system might emulate
a command processor by parsing the command and turning into the arguments to a
process-spawning function call. If the system has a command processor, then the
expectation is that system will use that command processor.
> that is performed by the command line prompt (cmd.exe). Try something like
> this:
>
> system("cmd /c PAUSE");
So what you are probably doing here is passing the command "cmd /c PAUSE" to
the command processor, which is is probably CMD itself. I.e you're
quite probably executing "cmd /c cmd /c pause", which is redundant.
stan
> stan said:
>> Richard Heathfield wrote:
>>> Helge Kruse said:
>>
>> <snip>
>>
>>> Er, so what? system("PAUSE") works just fine, in the sense that
>>> it will execute the PAUSE command, if there is one.
>>>
>>>> Try something like this:
>>>>
>>>> system("cmd /c PAUSE");
>>>
>>> I don't see what difference that would make.
>>
>> I don't disagree with you Richard, but it does make the code even
>> LESS portable.
>
> I don't see how it makes a significant difference. Calling system()
> is already enough to blow away any vestiges of portability. How you
> call it pales in comparison.
I won't argue that it's not a distinction without difference. If I write
and distribute my own pause with my app it would be somewhat more
portable. Relying specifically on a cmd app that is or clones DOS is
arguably impossible or impractical on many systems. In contrast I think
I have a fighting chance at implementing a pause on many systems.
We are in violent agreement that system is not portable. I'm taking into
consideration that I can extend the "system" capabilities with user
apps.
Rui Maciel
> Thanks, that works the same way the system ("PAUSE");
> So, is the use of it a bad practice?
Yes. By using system("pause") you are relying on a crude hack which is very platform specific to perform a
task that you shouldn't perform anyway. You are better off taking that piece of code (or equivalent code) out
of your program and instead run the binary through a command line script. In fact, IIRC that is the approach
used by bloodshed's Dev-C++.
Hope this helps
Rui Maciel
Rui Maciel
> Consider why you want your program to pause. If it's because you
> want the reader to have time to read the text on a console, why not
> do it like this?
Wouldn't it be better to run the compiled program from a batch file/shell script and simply avoid any
"pause"-ish hack?
Rui Maciel
Jerry Coffin
[ ... ]
> So what you are probably doing here is passing the command "cmd /c PAUSE" to
> the command processor, which is is probably CMD itself. I.e you're
> quite probably executing "cmd /c cmd /c pause", which is redundant.
It's likely to be redundant most of the time. In theory, however, it
wouldn't necessarily be. Just for example, consider somebody running
Windows with cygwin, who's set cygwin's bash as their default shell.
If they attempt to use pause directly, it'll fail because it's
neither an available executable nor a bash internal command. If they
use the 'cmd /c pause', bash will find cmd.exe and execute it,
passing '/c pause' as the parameters, which will work.
Of course, this isn't exactly the most common configuration, but it's
certainly not completely unthinkable either.
--
Later,
Jerry.
Richard Heathfield
If he wants to pause in the middle of processing, or only in certain
circumstances, then that won't work.
Keith Thompson
I think the most common scenario is writing what Windows calls a
console program (i.e., one that communicates using stdin and/or
stdout) in some kind of IDE. Typically you can run the program by
clicking on an icon. Building a wrapper script to execute the program
isn't difficult, but it's at least an order of magnitude more work.
The real answer is for the IDE itself to provide a way to run the
program and keep the window open. I think most of them provide such a
feature, but it's not the default behavior.
Disclaimer: I don't do Windows programming, so I could be wrong on
this.
Blue_Hat
> Jerry Coffin said:
>
>> In article <ln4ou2o...@nuthaus.mib.org>, ks...@mib.org says...
>>
>> [ ... ]
>>
>>> So what? There's no portable way to do what the PAUSE command
>>> does anyway (it waits for a single character input, without
>>> waiting for
>>> a new-line). If that's what you want to do, then system("PAUSE")
>>> is certainly an easier way to do it than using whatever
>>> system-specific libraries are necessary to reinvent that
>>> particular wheel.
>> Rather the contrary: giving any assurance that it will work
>> correctly (e.g. will actually find 'pause.exe' to execute) becomes
>> fairly difficult.
>
> Extremely difficult, unless you've written a pause.exe yourself or
> bought/found one from somewhere. Microsoft's PAUSE command is an
> *internal* command, which is part of the command processor. There
> is no pause.exe anywhere.
>
> <snip>
>
stopped using that in my codes.
How about cin.get()?
Ulrich Eckhardt
[alternatives to system("pause")]
> How about cin.get()?
void
wait_for_enter() {
std::cout << "<enter>" << std::endl;
std::string dummy;
getline(std::cin, dummy);
}
Reasons:
Input is line-buffered. That means that you can press several keys and only
when you press enter they actually become visible, even for the single-char
get() function.
Problems:
If you use "std::cin >> some_value" to read something, this operation will
leave anything beyond the value in the input buffers, including the
linebreak that the user entered. There are three possible solutions to this:
1. You only use this to not close the terminal window that e.g. MSVC opens
for you but otherwise the program runs non-interactively. Then you can use
this as-is, no input should be buffered before.
2. You are writing an interactive program but you are only using line-based
input. IOW, you always retrieve an answer from the user with getline() and
then validate/parse that answer. This is actually a good approach because it
allows the user to input strings with spaces in them and automatically
discarding trash from the input. Also, entering two values where one is
expected doesn't confuse the next input operation. In this case, the
approach works, too, since the buffer is always empty.
3. You use the shift operators to read input. In that case, you will first
have to flush and discard the input buffers using istream's ignore()
function.
Uli
Francis Glassborow
Actually I disagree with much that has been written in this thread
(what's new? :-) ) The problem is that if I want to pause I would prefer
to not have to 1) clear the input buffer 2) tell the user to press
return (because things like cin.get() will use whatever is already
waiting for processing, and when the input buffer is empty will then
wait for the user to signify that keyboard input has been completed be
pressing return)
Sometimes I do not have a system where I can do any form of raw keyboard
scan but one advantage of system('pause') is that where a raw keyboard
scan is available it can be used. Yes, the resulting code is less
portable but in reality a great deal of code is non-portable and the
authors of it do not want to jump through hoops to make it portable when
they do not need it to be.
As always, I would encapsulate non-portable code in a function that can
be rewritten for porting purposes so:
void pause(char* prompt){
puts(prompt);
system("pause");
}
and I can change that for systems that do not have such a system call.