wer programmiert eigentlich noch Konsolenanwendungen

[Mechanics]

Ganz einfach (ok, in Wirklichkeit nicht ganz so einfach), Logik und Darstellung trennen. Die Logik darf nie irgendwas von irgendeinem Benutzerinterface wissen (z.B. kein cout in Logik Code).

[Anfänger_2]

Mechanics schrieb:

Ganz einfach (ok, in Wirklichkeit nicht ganz so einfach), Logik und Darstellung trennen. Die Logik darf nie irgendwas von irgendeinem Benutzerinterface wissen (z.B. kein cout in Logik Code).

Das ist mir schon klar, ich wollte nur wissen, wie du das programmierst.
Du mußt die Ausgabe mit cout ja irgendwo unterbringen.

[cooky451]

Anfänger_2 schrieb:

Du mußt die Ausgabe mit cout ja irgendwo unterbringen.

Ja aber wenn das Programm so aussieht:

cin >> foo >> bar >> baz;
blubb = bla(foo, bar, baz);
cout << blubb;

Und hinter bla stehen 15k Zeilen Code, dann hast du trotzdem nicht sehr viel Zeit mit Konsolenkram verbracht, und dir dürfte letztlich auch egal sein wie und wo das Ergebnis angezeigt wird.

[hustbaer]

accon schrieb:

.... Wie macht ihr das?

Ich programmiere oft Commandline-Tools.

Ich beobachte aber bei meinen Kollegen eine recht starke Tendenz Dinge mit grafischen Tools machen zu wollen, wo grafische Tools mMn. gar keinen Sinn machen.

[Mechanics]

Anfänger_2 schrieb:

Du mußt die Ausgabe mit cout ja irgendwo unterbringen.

Wir reden vielleicht ein bisschen aneinander vorbei. Mir gings nicht darum, dass man nie überhaupt auch nur eine Zeile UI Code schreibt, entscheidend ist wo. Was ich hier oft sehe, sind irgendwelche Fragen zu Code, wo es dann z.B. eine Klasse "Person" gibt, und in der Klasse wird mit cin und cout hantiert. Oder Eine Klasse, die die Spiellogik "kapselt", und dabei wieder cin und cout verwendet. Das ist der falsche Ansatz. Eine Klasse, die irgendwelche Logik kapselt, darf überhaupt nichts darüber wissen, ob man die dann verwendet, um irgendwas auf der Konsole auszugeben oder 3D Animation darzustellen.
Und wie cooky geschrieben hat, ist es dann ja auch egal, wenn man irgendwo anders die Daten dann auf der Konsole ausgibt. Ja und? Dann hab ich noch irgendein Userinterface drangeklatscht, mein Code ist davon unabhängig. Und das war ja auch die Frage vom TE. Wenn man eine Schach KI programmiert, sollte man sich auf die Schach KI konzentrieren und sie so aufbauen, dass man sie sowohl auf der Konsole als auch in einem 3D Schachspiel verwenden können sollte.

[Anfänger_2]

Mechanics schrieb:

Anfänger_2 schrieb:

Du mußt die Ausgabe mit cout ja irgendwo unterbringen.

Wir reden vielleicht ein bisschen aneinander vorbei. Mir gings nicht darum, dass man nie überhaupt auch nur eine Zeile UI Code schreibt, entscheidend ist wo. Was ich hier oft sehe, sind irgendwelche Fragen zu Code, wo es dann z.B. eine Klasse "Person" gibt, und in der Klasse wird mit cin und cout hantiert. Oder Eine Klasse, die die Spiellogik "kapselt", und dabei wieder cin und cout verwendet. Das ist der falsche Ansatz. Eine Klasse, die irgendwelche Logik kapselt, darf überhaupt nichts darüber wissen, ob man die dann verwendet, um irgendwas auf der Konsole auszugeben oder 3D Animation darzustellen.
Und wie cooky geschrieben hat, ist es dann ja auch egal, wenn man irgendwo anders die Daten dann auf der Konsole ausgibt. Ja und? Dann hab ich noch irgendein Userinterface drangeklatscht, mein Code ist davon unabhängig. Und das war ja auch die Frage vom TE. Wenn man eine Schach KI programmiert, sollte man sich auf die Schach KI konzentrieren und sie so aufbauen, dass man sie sowohl auf der Konsole als auch in einem 3D Schachspiel verwenden können sollte.

Okay, einfache Frage.

Wie würdest du die Ausgabe lösen, wenn du einen BubbleSort Algorithmus schreiben sollst (der Logikteil) und dann jeden Schritt des Algorithmus auf der Konsole ausgeben sollst.

Wo packst du deine cout Sachen hin, oder besser, printf wenn es in C nicht objektorientiert sein soll?
In die Schleife des BubbleSort Algorithmus oder irgendwie ausserhalb
und wenn letzteres gilt, wie übergibst du die Daten aus dem Bubblesort Algorithmus nach außen, ohne dessen Schleife zu beenden?

[SeppJ]

Anfänger_2 schrieb:

Wie würdest du die Ausgabe lösen, wenn du einen BubbleSort Algorithmus schreiben sollst (der Logikteil) und dann jeden Schritt des Algorithmus auf der Konsole ausgeben sollst.

Schlechtes Beispiel, Wenn die Anforderung ist, eine Visualisierung von irgendetwas zu schreiben, dann wird da auch irgendwo konkreter Visualisierungscode drin sein.

[EOP]

Mach auch noch in Konsole.
Wenns q+d sein soll oder es nicht jeder Vollpfosten bdienen können soll.

[Shade Of Mine]

Anfänger_2 schrieb:

Okay, einfache Frage.

Wie würdest du die Ausgabe lösen, wenn du einen BubbleSort Algorithmus schreiben sollst (der Logikteil) und dann jeden Schritt des Algorithmus auf der Konsole ausgeben sollst.

Dann hast du ein Visualisierungsobjekt dem du in den jeweiligen Schritten des Algorithmus die jeweiligen Daten uebergibst und der macht dann damit seine Black Magic. Ob er es in OpenGL plottet oder einfach nur in eine Textdatei schreibt bleibt ihm ueberlassen.

Wo packst du deine cout Sachen hin, oder besser, printf wenn es in C nicht objektorientiert sein soll?

Man kann auch ohne OOP abstrahieren.

[Gast]

Nur ist es nicht mehr ganz so trivial bei langlaufenden Aktionen wie z.B. der Schach-KI die 30 Sekunden rechnet. In der Console kein Problem, eine blockierende GUI will aber niemand.
Also startet die GUI-Variante einen Thread und stößt die Berechnung an. Dazu muss die langlaufende Methode aber wenigstens Statusupdates per Event feuern und regelmäßig prüfen ob sie sich per Kommando von außen beenden soll. Eben per Objekt das man zusätzlich übergibt und diese Funktionalität anbietet.

Alles kein Hexenwerk. Aber man muss ein paar Kleinigkeiten berücksichtigen, weil sich eventbasierte GUI-Anwendungen anders verhalten als Consoleprogramme oder rein schleifengesteuerte OpenGL-Programme.

Außerdem wird hier der Aufwand für eine gute GUI unterschätzt. Die klatscht man nicht mal eben dran, wenn sie nach mehr als Win95 aussehen soll und eine gute Bedienbarkeit bietet. Nö, ich mag GUI-Programmierung auch nicht, aber sie ist nicht die reine Nebensächligkeit, als die sie gerne dargestellt wird.

[Shade Of Mine]

µ schrieb:

Außerdem wird hier der Aufwand für eine gute GUI unterschätzt. Die klatscht man nicht mal eben dran, wenn sie nach mehr als Win95 aussehen soll und eine gute Bedienbarkeit bietet. Nö, ich mag GUI-Programmierung auch nicht, aber sie ist nicht die reine Nebensächligkeit, als die sie gerne dargestellt wird.

GUIs zu implementieren sind absolut trivial.
Der Aufwand ist das GUI Design.

[Gast]

Shade Of Mine schrieb:

GUIs zu implementieren sind absolut trivial.
Der Aufwand ist das GUI Design.

Hör doch auf Blech zu reden.
GUIs sind nichts hochkomplexes aber sie pauschal als absolut trivial zu bezeichnen ist Unsinn.

[Mechanics]

Es ist immer gewisser Aufwand, eine GUI hinzubekommen, die nicht nur aus Standardcontrols besteht. Und dann muss es nicht mal langweilig sein. Was ich überhaupt nicht mag, sind Standardsachen. Wenn ich zu einem Projekt noch zusätzlich irgendein Fenster zusammenbauen muss, um zig Parameter einzustellen, finde ich das natürlich einfach nur lästig. Aber wenn man eine komplexere Oberfläche braucht, z.B. um Daten zu visualisieren, und das dann auch so aufbaut, dass es flexibel und performant ist usw., dann kanns durchaus auch Spass machen.
Und ja, man muss manchmal auch den Kern anpassen, damit er der GUI passt, das lässt sich leider nicht immer vermeiden. Trotzdem muss man das so machen, dass es flexibel bleibt und immer noch "Sinn macht", und nicht damit man gleich auf den ersten Blick erkennt, diese Extrafunktionalität ist jetzt nur in die API aufgenommen worden, damit man in dem einen Fenster da noch was sortieren kann.

[Shade Of Mine]

GUIs sind so wahnsinnig komplex, dass man die meisten GUI Anwendungen zusammenklicken kann.

[entity]

Kein ernst zunehmender Programmierer klickt die GUI zusammen. Das machen nur Anfänger. Oder mal kurz für Tools die unter einer Woche in der Entwicklung benötigen.

[Du redest Blech]

Shade Of Mine schrieb:

µ schrieb:

Außerdem wird hier der Aufwand für eine gute GUI unterschätzt. Die klatscht man nicht mal eben dran, wenn sie nach mehr als Win95 aussehen soll und eine gute Bedienbarkeit bietet. Nö, ich mag GUI-Programmierung auch nicht, aber sie ist nicht die reine Nebensächligkeit, als die sie gerne dargestellt wird.

GUIs zu implementieren sind absolut trivial.
Der Aufwand ist das GUI Design.

Dann schreib mal eine ohne Verwendung eines GUI Toolkit.

[berniebutt]

Was diskutiert ihr hier eigentlich?

Der Anwender wünscht Benutzerkomfort mit Visualisierung, also GUI-Anwendungen.
Frameworks und APIs stellen für GUI-Anwendungen hervorragende Hilfen für die Realisierung bereit.
Erforderliche Berechnungen erfolgen am besten getrennt von den GUI-Teilen in eigenständigen
Funktionen oder Klassen.

Mir sind Konsolenanwendungen seit langem ein Graus geworden. Auch für kleine Testprogramme und
zum Testen aufwendiger Algorithmen wähle ich immer eine GUI, die schnell zusammengeklickt ist.

[knivil]

Die meisten Unit-Tests sind Consolenanwendungen.

[berniebutt]

knivil schrieb:

Die meisten Unit-Tests sind Consolenanwendungen.

Bei Anwendungen mit dem Ziel einer Veröffentlichung oder eines Verkaufs bin ich mir da nicht sicher. Bleibt aber jedem selbst überlassen, wie er Unit-Tests macht.

[Shade Of Mine]

berniebutt schrieb:

knivil schrieb:

Die meisten Unit-Tests sind Consolenanwendungen.

Bei Anwendungen mit dem Ziel einer Veröffentlichung oder eines Verkaufs bin ich mir da nicht sicher. Bleibt aber jedem selbst überlassen, wie er Unit-Tests macht.

Nix für ungut, aber praktisch alle Unit Test Frameworks geben in der Konsole aus. Da gibt es nichts zu diskutieren, das ist einfach ein Fakt.