The short answer is: don't
And the simple answer is:
cout << string( 100, '\n' );
Things like PAUSE and CLS are antithetical to stream applications (or "console applications") because they violate a fundamental given:
|- The standard input and output may not necessarily be attached to a terminal. -|
There is some history to this. Before Unix and C came along, the poor saps programming on computer systems had to know how to connect with the desired I/O devices --which was often not a simple task, as each piece of hardware needed to be treated differently just to do something like, say, read a single character --or whatever you could get from the device. This made programs specific to particular pieces of hardware and often involved some complicated job setup scripts.
Unix (and consequently, C) introduced a groundbreaking concept that we take for granted today: I/O streams are decoupled from any specific device
(meaning that you can read and write characters and the OS handles all the underlying translations to and/or from specific devices) and they are automatically opened
when the program starts (meaning that the programmer doesn't have to know any particular magic to open them).
This abstraction also provided a powerful capability copied by nearly every major OS since: I/O redirection
|- Applications Shouldn't Control the User -|
So, putting a PAUSE or CLS in there kind of throws a wrench in all that. It means: "I don't care how you
want to control my program -- I demand that there be a human sitting in front of a terminal to run it."
Now, when you are writing and running the program yourself, you already know that there is a human sitting in front of a terminal (yourself). So it is fine to stick a system("PAUSE") in there so you can see it work properly. But once it is time to send it off to your professor or put it out on the internet or whatever, those kinds of demand constraints need to go, for the reasons above and also for those previously mentioned (including the fact that using system() is a positive security breach).
If I were teaching a C or C++ programming course, the very first day of class I would make it clear that anyone turning in homework with system() calls to things like PAUSE would loose
|- Acceptable Exceptions -|
There are, of course, times when a program should
require a human (such as a fullscreen text editor), or at least recognize when one is present. A very good article that covers all the important points is
fileno(3) on C++ Streams: A Hacker's Lament
In the case that you actually do need to manipulate the terminal directly, you should do so explicitly by using console-specific functions. I recommend the Curses
library, which works very well on a lot of platforms.
Windows, DOS, OS/2...
POSIX platforms (Unix, Linux, OS X...)
Both are highly compatible, and code written for one should work identically for the other. On most Linux systems, and many Unices, ncurses is already installed for you. Failing that apt-get
will install it for you.
Outside of a nice library like Curses, you must go straight to the OS to do things like clear the screen.
Performing a Clear Screen (CLS) in a Console Application
Again, for POSIX platforms, if you have terminfo
installed you also have curses installed. If you are on something really ancient that only has termcap
it is still worth your while to install ncurses because it will work with whichever of the two terminal databases it finds.
Whew. Hope this helps.