wer programmiert eigentlich noch Konsolenanwendungen

gedacht. Ich hab mit Kollegen lange diskutiert und will für dieses Projekt c++ nehmen und nicht c# oder Java. Ich hatte halt generell die Diskussion mit Kollegen die mich milde belächelt haben als ich gesagt habe, dass ich eigentlich nur Konsolenprogramme schreibe privat. Einige meinten dass es in Zeiten von so "Easy Frameworks" wie .net sowas von einfach wäre eine ordentliche Gui zu bauen und Konsolenanwendungen überholt und aus einem anderen Jahrzehnt sind. Darum auch die Frage wer überhaupt noch für Konsole programmiert. Ich persönlich finde es unglaublich gut weil man sich einfach auf den Code konzentrieren kann und nicht 100000 andere Sachen wie Fensterupdates etc. berücksichtigen muss

sollte sein dass ich mit jeder Karosserie fahren kann, aber der Motor darunter immer der gleiche ist, um es im übertragenen Sinne zu sagen. Persönlich denke ich dass WPF etc. ne wunderbare Sache ist, aber wenn ich nicht gerade für Anwender entwickle sprich meine Software verkaufen will dann tuts die Konsole meistens auch.

Mechanics

GUI Programmierung ist so oder so langweilig und eher Routine. Die meisten versuchen eher davon wegzukommen und Backend Code zu schreiben. Daher fällt die Frage, ob man GUI oder Konsolenanwendungen schreibt nicht so sehr ins Gewicht.

Aufwändig und gespickt mit Schwierigkeiten trifft's eigentlich eher als "langweilig und Routine", finde ich, es sei denn es handelt sich um Datenbank-Maskenprogrammierung... Das einzige was man dort natürlich nicht findet, sind Lösungen zu interessanten mathematischen Problemen (natürlich je nach Geschmack). Aber wenn's bunt und animiert ist, dann hat es auch ein gewisses Erfolgserlebnis dabei.........und verkauft sich gut.

cooky451

Also ich glaube 99% der Zeit schreibt man etwas was nichts mit Interfaces zu tun hat und ist daher weder Konsolen noch GUI Code?

Shade Of Mine

Kann mich nicht erinnern wann ich das letzte mal eine GUI angefasst habe... Aber vor Weihnachten muss ich noch irgendwann eine MFC Anwendung anfassen *brr*

SeppJ

Ich habe glaube ich ca. 5x im Leben eine GUI gemacht. Das dürfte wohl für so ziemlich jeden gelten, der keine Endanwendersoftware für "normale" Nutzer schreibt.

Mechanics schrieb:

Man sollte komplett GUI unabhängig programmieren. Dann ist völlig egal, ob man den Code dann in einer Konsolenanwendung, einer GUI Anwendung oder in einer Webanwendung nutzt.

Wie machst du das, gib mal Beispielcode.

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

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.

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.

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.

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.