C/C++ Forum :: Warum kein system("cls") verwenden?

Glen757 Mitglied 22:25:23 01.01.2012 Titel:

Hallo und ein frohes neues Jahr!

Meine frage ist, warum man kein system("cls") verwenden sollte.
Ich weiß zwar das es andere Methoden gibt, aber irgendwie versteh ich nich warum ich nicht system("cls") verwenden soll!

Selbst bei google hab ich so jetzt nichts gefunden.

Vielen dank für alle hilfen

Unregistrierter

Der Befehl braucht mehr Zeit und man hat keinen manchmal praktischen Verlauf zum durchblättern.

Du könntest einfach for(int i=0;i<80;i++)cout<<endl; schreiben.

volkard Moderator 23:09:21 01.01.2012 Titel:

'\n' statt endl.

Belli Mitglied 09:41:23 02.01.2012 Titel:

Thuruk schrieb:

Du könntest einfach for(int i=0;i<80;i++)cout<<endl; schreiben.

Das löscht aber nicht die Konsole und braucht möglicherweise noch mehr Zeit. Man kommt nicht drum rum, Funktionen des OS dafür zu benutzen, für Windows zB:

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14	1 2 3 4 5 6 7 8 9 10 11 12 13 14	void ClearScreen(void) { CONSOLE_SCREEN_BUFFER_INFO csbi; COORD target = {0, 0}; DWORD written; GetConsoleScreenBufferInfo(GetStdHandle(STD_OUTPUT_HANDLE), &csbi); FillConsoleOutputCharacter(GetStdHandle(STD_OUTPUT_HANDLE), ' ', csbi.dwSize.X * csbi.dwSize.Y, target, &written); FillConsoleOutputAttribute(GetStdHandle(STD_OUTPUT_HANDLE), 7, csbi.dwSize.X * csbi.dwSize.Y, target, &written); }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14	void ClearScreen(void) { CONSOLE_SCREEN_BUFFER_INFO csbi; COORD target = {0, 0}; DWORD written; GetConsoleScreenBufferInfo(GetStdHandle(STD_OUTPUT_HANDLE), &csbi); FillConsoleOutputCharacter(GetStdHandle(STD_OUTPUT_HANDLE), ' ', csbi.dwSize.X * csbi.dwSize.Y, target, &written); FillConsoleOutputAttribute(GetStdHandle(STD_OUTPUT_HANDLE), 7, csbi.dwSize.X * csbi.dwSize.Y, target, &written); }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14	void ClearScreen(void) { CONSOLE_SCREEN_BUFFER_INFO csbi; COORD target = {0, 0}; DWORD written; GetConsoleScreenBufferInfo(GetStdHandle(STD_OUTPUT_HANDLE), &csbi); FillConsoleOutputCharacter(GetStdHandle(STD_OUTPUT_HANDLE), ' ', csbi.dwSize.X * csbi.dwSize.Y, target, &written); FillConsoleOutputAttribute(GetStdHandle(STD_OUTPUT_HANDLE), 7, csbi.dwSize.X * csbi.dwSize.Y, target, &written); }

Martin Richter (MVP für C++) · Martin Richter Moderator 10:03:12 02.01.2012 Titel:

system erzeugt einen neuen COMMAND.COM Prozess... Warum einen Prozess starten, wenn man den Bildschirm mit simplen API Befehlen löschen kann.

Zudem: Weiß Du wirklich dass überall COMAND.COM installiert ist als command processor und CLS auch von diesem Processor unterstützt wird? :cool:

Unregistrierter

Ich muss zugeben ich kenne nicht alle MS-OS

Gab es da eines, welches command.com nicht unterstützte :confused:

Ja es gibt schon lange Jahre Gerüchte das MS da etwas reformieren will.

Da der Titel dieses Forums "DOS und Win32-Konsole" lautet schliesse ich Lösungen auf anderen OS einmal aus.

Etwas anderes wäre, wenn die selbe Frage in der C oder C++ Rubrik gestellt worden wäre.

Dann sind command.com oder cls in der Form nicht immer verfügbar.

Aber,wenn ihr andere Infos hab heraus damit.

MfG f.-th.

Shiba Mitglied 11:50:22 02.01.2012 Titel:

Meine Bemerkungen beziehen sich zu system() unter MS-Dos oder Windows.
Unter Linux ist das eventuell anders.

Wie Martin schon erwähnte, Du erzeugst einen neuen Prozess.
Das kann Ressourcenprobleme bedeuten.
Du musst sicherstellen, dass der Parameter von system() sinnvoll und vorhanden ist auf den Systemen, auf denen Dein Programm läuft. Persönlich betrachte ich den Parameter als freundliche, spekulative Annahme.
Dein Programm wartet im Ablauf darauf, dass ein Return zurück kommt bzw. der Prozess endet.
Das kann je nach Parameter von system eine Neu-Inszenierung von "Warten auf Godot" werden.
Die "bösen" Beispiele, die ich bis jetzt gesehen haben, weigerten sich auch konsequent den Return auszuwerten.
Der Return kommt übrigens von cmd.exe/coomand.com und muss nicht dem Return eines als Parameter auf gerufenen Programmes entsprechen. Du vergibst hiermit die Kontrolle über Deinen Programmfluss und kannst Fehler nicht abfangen oder verarbeiten. Willkommen auf der Dunklen Seite

Weiterhin hat der neue Prozess eine andere comspec- und path-Variable als der Aufrufende, nämlich die des aufgerufenen ( wenn vorhandenen ) cmd.exe.

Auch muss man aktuelle Streams flushen oder schliessen bevor man system nutzt.

Das Nutzen betriebssystemspezifischer Hardwarsteuerung(im Thread beschrieben) in eigenen Modulen/Bibliotheken ist sauberer und der Programmierer hält die Kontrolle über das Programm.

Glen757 Mitglied 14:26:10 02.01.2012 Titel:

Ok, viele dank für die schnellen Antworten

Jetzt kapier ich das auch endlich mal

volkard Moderator 20:52:33 02.01.2012 Titel:

Shiba schrieb:

Meine Bemerkungen beziehen sich zu system() unter MS-Dos oder Windows.
Unter Linux ist das eventuell anders.

Ganz sicher sogar, denn sonst würden wir über system("clear"); reden.

Shiba schrieb:

Wie Martin schon erwähnte, Du erzeugst einen neuen Prozess.
Das kann Ressourcenprobleme bedeuten.

Also reden wir über DOS. Da inkludiert man einfach die <conio.h> und hat clrscr();

Shiba schrieb:

Du musst sicherstellen, dass der Parameter von system() sinnvoll und vorhanden ist auf den Systemen, auf denen Dein Programm läuft.

cls ist ein interner befehl der command.com bzw cmd.exe
Es ist sichergestellt, daß system("cls") geht.

Shiba schrieb:

Persönlich betrachte ich den Parameter als freundliche, spekulative Annahme. Dein Programm wartet im Ablauf darauf, dass ein Return zurück kommt bzw. der Prozess endet. Das kann je nach Parameter von system eine Neu-Inszenierung von "Warten auf Godot" werden.

Du redest gar nicht von system("cls"), sondern vor irgendwelchen anderen Aufrufen mit system. Das ist ein großer Unterschied.

Shiba schrieb:

Die "bösen" Beispiele, die ich bis jetzt gesehen haben, weigerten sich auch konsequent den Return auszuwerten.

???

Shiba schrieb:

Der Return kommt übrigens von cmd.exe/coomand.com und muss nicht dem Return eines als Parameter auf gerufenen Programmes entsprechen.

Naja, ist bei cls nicht soo schlimm: völlig irrelevant.

Shiba schrieb:

Du vergibst hiermit die Kontrolle über Deinen Programmfluss und kannst Fehler nicht abfangen oder verarbeiten. Willkommen auf der Dunklen Seite

Naja, ist bei cls nicht soo schlimm: völlig irrelevant.

Shiba schrieb:

Weiterhin hat der neue Prozess eine andere comspec- und path-Variable als der Aufrufende, nämlich die des aufgerufenen ( wenn vorhandenen ) cmd.exe.

Ist das bei cls ein Problem?

Shiba schrieb:

Auch muss man aktuelle Streams flushen oder schliessen bevor man system nutzt.

Muß man auch bei den API-Methoden.

Shiba schrieb:

Das Nutzen betriebssystemspezifischer Hardwarsteuerung(im Thread beschrieben) in eigenen Modulen/Bibliotheken ist sauberer und der Programmierer hält die Kontrolle über das Programm.

Generell: Ja.
Bei cls: Eher egal.

Ich fürchte, es bleiben keine nennenswerten Argumente gegen system("cls") übrig. Nur eines:
system ist generell schlimm und man vermeidet es, wenn es einfach geht. Bei cls geht es einfach. Also ist das der ideale Trainingsgrund, das mal zu üben.

Shiba Mitglied 09:53:41 03.01.2012 Titel:

Es sind Argumente gegen sytem().
Ich meinte die Windows Konsole.
clrscr finde ich in der conio.h meines Compilers nicht.

volkard Moderator 10:06:16 03.01.2012 Titel:

Shiba schrieb:

clrscr finde ich in der conio.h meines Compilers nicht.

Welcher Compiler? Insbesondere: Ist er für DOS und nicht fpr die Win32-Konsole?

Unregistrierter

Unter DOS hatten Borland-Compiler in der conio.h clrscr.

Bei DOS-Compilern der Mitbewerber wie Microsoft, Zorland/Symantec/Digital-Mars oder Watcom gab/gibt es vergleichbare Funktionen, teilweise in anderen Headern, mit unter Umständen deutlich abweichenden Namen.

MfG f.-th.

Unregistrierter

Hab das mal für den Digital-Mars Compiler heraus gesucht:

C/C++ Code:
#include <disp.h> disp_move(0,0); disp_eeop();

C/C++ Code:
#include <disp.h> disp_move(0,0); disp_eeop();

C/C++ Code:
#include <disp.h> disp_move(0,0); disp_eeop();

das entspricht bei Borland

C/C++ Code:
clrscr();

C/C++ Code:
clrscr();

C/C++ Code:
clrscr();

funktioniert noch auf dem free bcc 5.5

Hier mal ein Link:
http://www.shedai.net/c/new/PCLRSCRN.HOW

Es gibt auch noch mehrere Tools die den Borland Syntax für andere Compiler zur Verfügung stellen. Beispiel hier aus dem Forum: Improved Console 4.0.
Es gibt da auch noch andere Werkzeuge :live:

Viel Spass
f.-th.

volkard Moderator 10:36:20 03.01.2012 Titel:

Danke für den Link.

Shiba Mitglied 10:37:26 03.01.2012 Titel:

Die Visual Studio Compiler haben kein clrscr.
Wie schon bemerkt der alte Borland und andere schon.
Aber ich bin auch von Windows Konsolenprogrammen ausgegangen.
Wenn der Compiler es bietet, kann man es natürlich auch nutzen.

Unregistrierter

@Shiba schau in den Link von mir.
Die ersten VS-Versionen in den 90ern haben da noch die DOS-Variante. DOS in VS funktionierte nur bis VS 1.5 oder so?

Wenn ihr das real unter DOS lösen wollt, wie war noch mal der Interrupt? int 10h?
Da könnt ihr euch auch durch wühlen. Neuere Betriebssysteme erschweren einem ja diese hardwarenahen Lösungen

Bei aktuellen VS geht das über Windows.h.

MfG f.-th.

Unregistrierter

Da erwischt man sich wieder

Moderne OS natürlich nur, wenn Windows -> windows.h :o)

In Linux natürlich anders.

MfG f.-th.

Shiba Mitglied 15:22:33 03.01.2012 Titel:

Danke f.-th. für den Hinweis

Mir ging es allein um system() und da lag ich, wie Volkhard schon bemerkte, leicht nebendem Threadthema.

Unregistrierter

Zitat:

Die Visual Studio Compiler haben kein clrscr.

Wenn der Code dazu nun bei einem anderen Compiler vorliegt, kann man nicht einfach die Datei kopieren und dann #includen?

Unregistrierter

Kannst ja wegen dem Code bei Microsoft nachfragen :live:

Wenn du den bekommst, startest du die gleiche Frage bei den Borland/Embarcadero. Dann schaust du dir den Quelltext der Bibliotheken an und konstruierst da eine eigene daraus, lässt die von beiden Firmen lizenzieren u.s.w. :o)

Oder hast du etwas anderes geplant :confused:

Da geht noch was

Ich habe ja was von Werkzeugen oder Tools (muss wohl so :o)

) geschrieben.
Da gibt es dann mehrere verschiedene Varianten wie du deinen Lieblingscompiler mit entsprechenden Funktionen nachrüsten kannst.

MfG f.-th.

Belli Mitglied 12:07:46 04.01.2012 Titel:

Thuruk schrieb:

Zitat:

Die Visual Studio Compiler haben kein clrscr.

Wenn der Code dazu nun bei einem anderen Compiler vorliegt, kann man nicht einfach die Datei kopieren und dann #includen?

Ähh ... wenn Du Visual Studio benutzen willst, programmierst Du wohl für Windows. Dann kannst Du einfach die oben gepostete Funktion verwenden.

Josh.Schr. Mitglied 23:33:01 16.01.2012 Titel:

ich habe für meine win-konsolen-anwendung meine sysmte("CLS") befehle durch die funktion auf der ersten seite ersetzt. funktioniert alles auch wunderbar - genau wie es soll.
aber es gibt immernoch ein problem:
wenn ich recht schnell hintereinander die konsole leere - wieder beschreibe und wieder leere blinkt die erste bzw ersten zeilen. ich dachte das wäre durch deine funktion behoben.
gibt es noch eine andere möglichkeit?

Belli Mitglied 08:58:11 17.01.2012 Titel:

Was meinst Du mit 'recht schnell'?
Wenn ich morgens aus dem Haus gehe, mache ich das Licht aus. Wenn es abends dunkel wird, mache ich es wieder an.
Wenn ich das aber nun im Rhythmus einer halben Sekunde oft hintereinander mache ... dann blinkt es halt ...

Josh.Schr. Mitglied 11:17:59 17.01.2012 Titel:

okay, hier etwas genauer:
ich habe ein menü mit einer pfeil auswahl geschrieben. funktion: ich setze einen ascii pfeil auf auswahl 1, dann drücke ich die pfeiltaste nach unten.
dann lösche ich alle ausgaben auf der konsole mit system("cls") und schreibe nun das selbe menü wieder hin, nur das der pfeil nun bei option 2 davor steht, nicht mehr bei der ersten option.
wenn ich nun schnell die pfeiltasten hoch & runter drücke blinkt die erste zeile in meiner konsole kurz (ms). ich dachte das würde an meinem befehl system("cls") liegen, wegen os-befehl etc. aber mit der funktion auf seite 1 blinkt es immernoch für wenige ms in meiner konsole.

edit: es blinkt nur die erste zeile. die anderen zeilen, die auch immer gelöscht und wieder ausgegebn werden bleiben konstant stehen.

Belli Mitglied 12:21:55 17.01.2012 Titel:

Dafür würde ich nicht den ganzen Bildschirm löschen, sondern nur die Stelle, wo Dein zu löschender Text steht (Dein Ascii-Pfeil). Dann brauchst Du dafür auch nicht den ganzen Bildschirm neu zu beschreiben.

Wenn ich das richtig verstehe, würde es doch ausreichen:

Einmal Bildschirm löschen.
Einmal Menü ausgeben.

In einer Schleife:
Ascii-Pfeil an der gewünschten Stelle ausgeben.
Taste abwarten.
Ascii-Pfeil an der alten Stelle mit Blanks überschreiben.
Schleife wieder von vorne.

Belli Mitglied 12:26:59 17.01.2012 Titel:

Beispiel:

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21	1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21	#include <windows.h> void DruckSimpleText(int x, int y, char const text) { COORD target = {x, y}; DWORD written; WriteConsoleOutputCharacter(GetStdHandle(STD_OUTPUT_HANDLE), text, strlen(text), target, &written); } int* main() { for(int i = 0; i < 10; ++i) { DruckSimpleText(5, i, "===>"); Sleep(2000); DruckSimpleText(5, i, " "); } }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21	#include <windows.h> void DruckSimpleText(int x, int y, char const text) { COORD target = {x, y}; DWORD written; WriteConsoleOutputCharacter(GetStdHandle(STD_OUTPUT_HANDLE), text, strlen(text), target, &written); } int* main() { for(int i = 0; i < 10; ++i) { DruckSimpleText(5, i, "===>"); Sleep(2000); DruckSimpleText(5, i, " "); } }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21	#include <windows.h> void DruckSimpleText(int x, int y, char const text) { COORD target = {x, y}; DWORD written; WriteConsoleOutputCharacter(GetStdHandle(STD_OUTPUT_HANDLE), text, strlen(text), target, &written); } int* main() { for(int i = 0; i < 10; ++i) { DruckSimpleText(5, i, "===>"); Sleep(2000); DruckSimpleText(5, i, " "); } }

Josh.Schr. Mitglied 14:26:12 17.01.2012 Titel:

wow, vielen dank, das ist natürlich weitaus angenehmer und erspart mir auch ein paar Zeilen Code. Danke für den Hinweis! :live: