Thread: system("cls")

>system ("cls");
The system function should be avoided wherever possible. First is the portability issue (system is portable, but the argument cannot be), then there is the speed issue (system is very slow). Most of the time people clear the screen when they really don't need to.

I found this quote in a thread on the forum.

(1) Is there a faster, better, or more efficient way to do this?

-scrolling the screen is unacceptable.
e.g.

Code:

for(int x=0;x<81;x++)
    {
         cout<<"\n";
    }

(2) What clears the screen that is cross platform compatible (portable)?


A little further down the post I found this.

(3) How does hiding the system command make a program more portable?

Code:

 
#include <cstdlib>

// Easily changed
void screen_clear()
{
  system ( "CLS" );
}

int main()
{
  clear(); // Calls clear a lot, but that's okay. Porting is easier
}

>(1) Is there a faster, better, or more efficient way to do this?
Yes, but exactly what that way is will be implementation dependent. As an example, some compilers support a function called clrscr() in conio.h that clears the screen. This is a better option than the system function. Where you don't have the luxury of a prewritten compiler extension, you have to write your own. For that, please see our FAQ.

>-scrolling the screen is unacceptable.
Indeed it is. Unless you also have a way of moving the cursor back to a 0,0 location, this solution is ugly. It's also not wise since the actual size of the screen is usually unknown, so you can't be sure that you are clearing all of the screen or too much. You can find the dimensions if a screen is present, but after that this solution loses its novelty. Then there's the added portability problem of the C++ standard not even requiring that a screen be present.

>(3) How does hiding the system command make a program more portable?
Rather than sprinkling nonportable constructs all over your program and in the middle of portable constructs, you isolate them so that only one segment of your code has to be changed when the program is ported to another system. The alternative is to change every single occurance of the nonportable construct. As you can imagine, for larger projects, this would be a nightmare. Using the example you gave (that I gave originally), to port this code to, say, Unix, instead of changing every system call (which could number in the thousands for a large program), you would need to change only one thing, the implementation of screen_clear.

Note: I just noticed that I made a boo-boo. I define the function as screen_clear, but call it as clear. Baka.

I just use option 3 if i have to, but i try to avoid clearing the screen as much as possible...

Thank you for the input.

Follow up question:
(1) Is there a list of constructs (code) that is non-portable?
-I feel the best way is like you said confine the non-portable code to an individual function.

> Is there a list of constructs (code) that is non-portable?
If you wrote the function yourself, then it's portable
If the function you call is part of the standard library, then it's portable
Anything else is to some extent system specific.

> -I feel the best way is like you said confine the non-portable code to an individual function.
This is a good plan