C++ weiter nutzen oder Sprache Wechseln ?

Skym0sh0

dnce schrieb:

Da ich eigentlich gern denn bisherigen Code 1:1 verwenden würde wäre es gut bei C++ zu bleiben

Wenn dein Design nicht hinkommt, dann kannst du das mit dem Code behalten ganz schnell knicken. GUIs machen oft (eig. gewöhnlich) soviel Komplexität aus, dass es nicht unbedingt schwerer ist alles neu zu schreiben.

Jedenfalls auf dem Level, wo du dich befindest.

dnce

Skym0sh0 schrieb:

dnce schrieb:

Da ich eigentlich gern denn bisherigen Code 1:1 verwenden würde wäre es gut bei C++ zu bleiben

Wenn dein Design nicht hinkommt, dann kannst du das mit dem Code behalten ganz schnell knicken. GUIs machen oft (eig. gewöhnlich) soviel Komplexität aus, dass es nicht unbedingt schwerer ist alles neu zu schreiben.

Jedenfalls auf dem Level, wo du dich befindest.

Das habe ich mir schon fast gedacht...
Welche Sprache würdest du empfehlen ?

Benütz einfach Qt
http://qt-project.org/

Skym0sh0

Ich hab nicht gesagt, dass du wechseln musst oder sollst.

Aber du solltest dir bewusst machen, dass selbst simple GUIs schon recht viel Komplexität in dein Projekt bringen. Und je nachdem was du vorhast (z.B. Plattformunabhängigkeit), knallt das ganz schnell.

Empfehlungen für GUI-Bibliotheken hab ich nicht, denn letztlich ists egal wo du dich rein arbeitest. Es ist zu Beginn viel Arbeit (allein schon so "einfache" Dinge wie Projekteinstellungen richtig setzen und dann compilen) und früher oder später wirst du mal richtig fluchen wie scheisse denn deine Bibliothek oder dein Framework ist.

Umgekehrt wäre es auch vielleicht ne gute Übung bewusst eine andere Sprache zu nehmen, allerdings exklusiv für die GUI. Z.B. baust du dir mit Java oder C# ne GUI und lädst deine Programmlogik als DLL in C++ nach.

audacia

Skym0sh0 schrieb:

Umgekehrt wäre es auch vielleicht ne gute Übung bewusst eine andere Sprache zu nehmen, allerdings exklusiv für die GUI. Z.B. baust du dir mit Java oder C# ne GUI und lädst deine Programmlogik als DLL in C++ nach.

Das würde ich tunlichst bleibenlassen. Sowas bringt fast immer eine enorme Komplexität mit sich, und man sollte schon ausführliche Kenntnisse von der Funktionsweise der Interop-Mechanismen haben, sonst kann man das eigentlich nur falsch machen. (Ausnahmen sind .NET-Sprachen wie C# und F#, die man sehr einfach miteinander kombinieren kann, oder z.B. Delphi und C++Builder, aber um sowas gehts ja nicht.)

@dnce: Ich würde auch dazu raten, Qt zu verwenden, weil es vermutlich am einfachsten ist. Eine qualifizierte Entscheidung über GUI-Toolkits kannst du eh erst treffen, wenn du mal ein paar davon gesehen hast, und wenn ich's recht verstehe, willst du gerade nur ein GUI für dein Projekt machen und nicht möglichst viel über verschiedene GUI-Toolkits lernen.

audacia schrieb:

Skym0sh0 schrieb:

Umgekehrt wäre es auch vielleicht ne gute Übung bewusst eine andere Sprache zu nehmen, allerdings exklusiv für die GUI. Z.B. baust du dir mit Java oder C# ne GUI und lädst deine Programmlogik als DLL in C++ nach.

Das würde ich tunlichst bleibenlassen. Sowas bringt fast immer eine enorme Komplexität mit sich, und man sollte schon ausführliche Kenntnisse von der Funktionsweise der Interop-Mechanismen haben, sonst kann man das eigentlich nur falsch machen.

Sehe ich komplett anders. Es mag zu Anfang komplizierter sein, aber später zwingt einem diese Architektur die Disziplin GUI und Logik Code säuberlich zu trennen automatisch auf.

Skym0sh0

Morle schrieb:

audacia schrieb:

Skym0sh0 schrieb:

Umgekehrt wäre es auch vielleicht ne gute Übung bewusst eine andere Sprache zu nehmen, allerdings exklusiv für die GUI. Z.B. baust du dir mit Java oder C# ne GUI und lädst deine Programmlogik als DLL in C++ nach.

Das würde ich tunlichst bleibenlassen. Sowas bringt fast immer eine enorme Komplexität mit sich, und man sollte schon ausführliche Kenntnisse von der Funktionsweise der Interop-Mechanismen haben, sonst kann man das eigentlich nur falsch machen.

Sehe ich komplett anders. Es mag zu Anfang komplizierter sein, aber später zwingt einem diese Architektur die Disziplin GUI und Logik Code säuberlich zu trennen automatisch auf.

Genau :>

Ethon

Schreib's in Java.

audacia

Morle schrieb:

Sehe ich komplett anders. Es mag zu Anfang komplizierter sein, aber später zwingt einem diese Architektur die Disziplin GUI und Logik Code säuberlich zu trennen automatisch auf.

Echt jetzt? Also nur weil er sich mit, sagen wir mal, dem JNI rumschlagen muß, damit er ein paar Funktionen seiner Klasse in C++ implementieren kann, beginnt er automatisch, "GUI und Logik Code säuberlich zu trennen"?

Es gibt schon Möglichkeiten, sich zur Selbstdisziplin zu zwingen, z.B. wenn man ein Framework mit expliziter Model/View-Unterstützung verwendet (z.B. WPF, aber Qt hat sowas auch). Wenn der Threadersteller diese Separation über eine Sprachbarriere zu erzwingen versucht, dann prophezeie ich, daß er den weitaus größten Teil seiner Zeit damit verbringt, die JNI-Dateien in das C++-Buildsystem seiner Wahl einzugliedern, sein JNI-Binding zu debuggen, manuellen Marshalling-Code zu schreiben und sich einzulesen, wie sich das Java-Speichermodell von dem in C++ unterscheidet, inwieweit man das berücksichtigen muß und warum sein Programm crasht, wenn er ein jclass außerhalb der JNI-Funktion speichert. Oder wenn er C++/CLI verwendet, wird er mit dem Schreiben von managed wrapper classes beschäftigt sein, sich dauernd Workarounds suchen müssen für den Umstand, daß er keine unmanaged classes als Membervariablen haben kann, und evtl. sein Vergnügen mit der Initialisierung statischer Variablen haben. Desgleichen mehr bei einem Skriptsprachenbinding. All das ist sicher ungeheuer lehrreich, aber zum Angewöhnen von MVP/MVC finde ich es ziemlich ineffektiv

dnce schrieb:

ein Programm dass Texte oder ähnliches in Bilder integrieren und mit einem Passwort verschlüsseln kann.

Hat denn keiner von euch mal gelesen, was hier überhaupt gewünscht ist? Wie kann man hier riesige Bastelein mit JNI und was weiß ich denn noch empfehlen?

Das ist doch ein 1a-Fall dafür, das bestehende Kommandozeilenprogramm einfach mit den nötigen Daten als Argument bzw. auf Stdin aus dem GUI-Programm aufzurufen und das Ergebnis entgegenzunehmen. Anstatt Herumfummelei mit JNI ist das dann ein einfaches fork/exec (oder popen).

Für die GUI kann man dann auch das nehmen, was am ehesten geeignet ist. Ich empfehle Tcl mit Tk als Toolkit. Das ist für GUIs immer noch das beste. Alles andere wirkt einfach nur wie gewollt, aber nicht gekonnt.