Warum kein system("cls") verwenden?



  • 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 😃



  • 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.



  • '\n' statt endl.



  • 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:

    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);
    }
    


  • 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? 🕶



  • Ich muss zugeben ich kenne nicht alle MS-OS 😉

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

    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.



  • 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.



  • Ok, viele dank für die schnellen Antworten 😃

    Jetzt kapier ich das auch endlich mal



  • 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.



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



  • 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?



  • 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.



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

    #include <disp.h>
    
    disp_move(0,0);
    disp_eeop();
    

    das entspricht bei Borland

    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 👍

    Viel Spass
    f.-th.



  • Danke für den Link. 🙂



  • 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.



  • @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.



  • Da erwischt man sich wieder 😃

    Moderne OS natürlich nur, wenn Windows -> windows.h 🤡
    In Linux natürlich anders.

    MfG f.-th.



  • Danke f.-th. für den Hinweis 🙂
    Mir ging es allein um system() und da lag ich, wie Volkhard schon bemerkte, leicht nebendem Threadthema.



  • 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?



  • Kannst ja wegen dem Code bei Microsoft nachfragen 👍
    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. 🤡
    Oder hast du etwas anderes geplant 😕
    Da geht noch was 😉

    Ich habe ja was von Werkzeugen oder Tools (muss wohl so 🤡 ) geschrieben.
    Da gibt es dann mehrere verschiedene Varianten wie du deinen Lieblingscompiler mit entsprechenden Funktionen nachrüsten kannst.

    MfG f.-th.


Anmelden zum Antworten