[C++] Gui

[Murphy7]

Ich kann die kann die Grundlagen von C++ jetzt. Nur stört mich das es immer nur in der Konsole ist. Wie mache ich dass das es Grafisch ist also ein Gui. Gibt das da irgendwo ein Tutorial, dies sollte am besten kostenlos kann aber auch was kosten.
Ich benutze zur Zeit Microsoft Visual C++ 2008 und habe Windows Vista. Ich hab da mal was MFC gelesen, ich weiß nicht was das ist.
Das Tutorial sollte die Grundlagen von Gui behandeln. Soll aber für C++ sein.

 

[Boron]

Für C++ ist Qt sehr zu empfehlen: www.qtsoftware.com (es gibt sogar Bindings zu anderen Sprachen: Python, .NET usw.; so lässt sich Qt selbst abseits der C++ Welt nutzen).
Die Bibliothek (inklusive Oberflächendesigner, hervorragender Hilfe und vielen Beispielen und Tutorials) gibt es als Opensourceversion zum runterladen.

Die Nutzung der Qt Klassen ist sehr einfach zu erlernen, fast schon intuitiv.
Hier mal einlesen: http://www.qtsoftware.com/products
Die Onlinehilfe ist hier: http://doc.qtsoftware.com/4.5/index.html (das wird aber auch beim Download mitgeliefert).

Unbedingt den Getting Started Teil lesen!

 

[GustlPC]

Hallo,

ich benutze Mit Borland Builder die VCL. Ich fand den Einstieg mehr als einfach.

QT wurde mir schon öfters empfohlen, bin aber immer wieder von einem Umstieg abgeschreckt...
Wie ich das verstanden habe muss man mit QT jedes kleine Fenster, bzw. edit, button selber coden... oder seh ich das falsch? Mit welchem compiler arbeitet man mit der gui?
Bei VCL zieh ich halt einfach nur, zb. einen Button , die Komponente rein und ich kann drauf los schreiben?

Das stell ich mir mit QT etwas schwerer vor...

Über QT soll es auch ein gutes Buch in deutsch geben...

Gruß
Gustl

 

[roker002]

unter ressourcen kannst du dir auch einen dialogfeld zusammenbasteln. den musst du dir halt nur hinzufügen! Das ist das einfachste was man anbieten kann wenn man VS9 benutzt.

wenn du englisch kannst, dann hier gucken. da sind fast alle instanzen von MS, sogar die aktuellen aufgelistet.
http://functionx.com/

 

[Boron]

Man programmiert nicht "unter Qt".
Qt ist, wie schon gesagt, "nur eine C++ Klassenbibliothek". Wie es auch die MFC ist. Das ist auch nur eine Bibliothek, die in C++ Programmen benutzt werden will.

Man kann Qt-Oberflächen komplett manuell programmieren, kann aber auch einen Oberflächendesigner nutzen (Qt Designer).
Qt bietet nicht nur Klassen um Oberflächen zu erstellen, sondern auch jede Menge anderer Klassen: QString, QTimer, QFile, QXmlStreamReader und verdammt viele mehr.
Das heiß, man kann auch Konsolenanwendungen schreiben, die Qt Klassen nutzen.

Nahezu jeder Compiler kann zum übersetzen für Programme, welche die Qt Bibliothek nutzen, benutzt werden.
Ich hänge mal eine Liste an. In der ist nahezu jeder Compiler und jedes System aufgelistet.

Wenn man nicht darauf steht alles von Hand zu machen können Qt-Projekte auch im MS VisualStudio entwickelt werden. Oder in Eclipse, oder in CodeBlocks oder in ...

Bücher gibt es auch einige über Qt: http://www.qtsoftware.com/developer/books
Auch in Deutsch.

Die Lernkurve zur Qt Bibliothek ist sehr steil.
Will heißen, dass man sehr schnell viel über die Bibliothek und deren Anwendung lernt (Beispiele und Tutorials habe ich schon erwähnt). Einsteiger haben schnell Erfolgserlebnisse und bleiben dabei. So war das bei mir. Während des Studiums habe ich zum ersten Mal damit rumgespielt und war von Anfang an begeistert.

Grund für das alles ist ein sehr einheitliches Konzept bei den Klassen. Damit meine ich, dass alles irgendwie ähnlich ist. Kennt man das schon ein paar Klassen (und deren Methoden), dann ist es recht einfach neue Klassen zu benutzen, weil einem irgendwie alles bekannt vorkommt (ähnliche Methodennamen, oder zumindest bekanntes Namensschema). Man muss nicht jedes Mal umdenken.

(Ich komme mir grad vor wie ein Vetriebsmitarbeiter bei Qt Software. Bin ich aber nicht . Bin nur ein Qt-Fan)

 

[XunnD]

wxWidgets könnte man dann auch noch in die Runde werfen.

 

[Affe007]

Ich habe auch Erfahrung mit C/C++ aber als es dann an die GUI ging, hab ich es hingeschmissen (MFC suckt derbe, vll. bringt es Qt ja). Ich mach das jetzt mit C# und VS2009EE, das ist so simple das jeder sehr schnell ein GUI für sein Progrämmchen hinbekommt.
Wenn man dann noch in C++ mit Klassen gearbeitet hat ist der Umstieg auf C# auch nicht so wild.

 

[Stefan_Sch]

Ich kann auch Qt 4 empfehlen. Sehr leistungsfähig, plattformunabhängig und sauber konzipiert.

 

[roker002]

Ich habe auch Erfahrung mit C/C++ aber als es dann an die GUI ging, hab ich es hingeschmissen (MFC suckt derbe, vll. bringt es Qt ja). Ich mach das jetzt mit C# und VS2009EE, das ist so simple das jeder sehr schnell ein GUI für sein Progrämmchen hinbekommt.
Wenn man dann noch in C++ mit Klassen gearbeitet hat ist der Umstieg auf C# auch nicht so wild.

MFC ist ja ehe veraltet und sollte bald nicht mehr existieren.

Bin mit C# GUI builder komplett zufrieden! Von C++ auf C# ist eigentlich einfach umzusteigen!

 

[Stefan_Sch]

MFC ist ja ehe veraltet und sollte bald nicht mehr existieren.

Bin mit C# GUI builder komplett zufrieden! Von C++ auf C# ist eigentlich einfach umzusteigen!

C# hat mit C++ nix zu tun! Du stellst dich gerade so hin, als ob man von C++ auf C# umsteigt und quasi upgradet.

Das sind zwei vollkommen verschiedene Sprachen. C# basiert auf einer Plattform, nämlich .NET, während C++ direkt in Maschinencode kompiliert wird.

Einen GUI Builder gibt es auch für C++ unter Qt. Das ist für die Klickibunti-Fraktion hier im Forum.

Die MFC werden noch sehr lange existieren, das hat Microsoft öffentlich bestätigt. Auch wenn die MFC schon sehr alt sind, die Bibliothek wird zwar weiterhin weiterentwickelt, aber das Konzept stammt nunmal aus den 90igern.

Die gesamte CLR ist übrigens in C/C++ geschrieben. Genauso, wie der C# Compiler.

 

[XunnD]

Genau - wie kommt man nur auf die absolut absurde Idee, dass C# etwas mit C++ zu tun haben könnte...

Ich brauch nur die Syntax von C# hernehmen und kann rechtens behaupten, dass C# von C++ abstammt.

Natürlich macht man ein Upgrade - beispielsweise von unmanaged code zu managed code, von einer Framework-losen Sprache zu einer Framework-benötigenden Sprache, to be continued...
C# nimmt damit dem Programmierer im Wesentlichen Implementierungsarbeit ab (wie das bei Frameworks eben üblich ist), C# ist damit "bequemer" - der Programmierer kann weniger semantische Fehler machen.

 

[Stefan_Sch]

Genau - wie kommt man nur auf die absolut absurde Idee, dass C# etwas mit C++ zu tun haben könnte...

Es ging nirgends um die Frage was C# mit C++ zu tun hat!

C++ hatte Einfluss auf die Sytnax der Sprache C#. Sieht man sich die C Sprachfamilie an, kann man erkennen das diese auf viele moderne Sprachen Einfluss hatte, unter anderem PHP und Java.

Ich brauch nur die Syntax von C# hernehmen und kann rechtens behaupten, dass C# von C++ abstammt.

C# stammt nicht von C++ ab, C++ hatte Einfluss auf die Konzeption der Syntax von C#, so wie auch Delphi.

Natürlich macht man ein Upgrade - beispielsweise von unmanaged code zu managed code, von einer Framework-losen Sprache zu einer Framework-benötigenden Sprache, to be continued...

So ein Blödsinn! Sprichst du auch von einem Upgrade, wenn du von einem PKW in einen LKW steigst oder wie?

C# nimmt damit dem Programmierer im Wesentlichen Implementierungsarbeit ab (wie das bei Frameworks eben üblich ist), C# ist damit "bequemer" - der Programmierer kann weniger semantische Fehler machen.

Richtig. C# nimmt einem aber hauptsächlich aufgrund der riesigen Klassenbibliotheken Implementierungsarbeit ab.

Der wesentliche Unterschied zu C++ liegt darin, das C# in Bytecode kompiliert wird, der von einer VM in Maschinencode gejitted wird. Die Laufzeit kann daher Einfluss auf die Programmausführung nehmen, was bei C++ so nicht mehr möglich ist, weil C++ direkt in CPU Instruktionen kompiliert wird.

Das eröffnet zum Beispiel Möglichkeiten in der Erhöhung der Laufzeitsicherheit, der dynamischen Optimierung der Speicherverwaltung und Easy-Reflection.

DAS sind die wesentlichen Unterschiede!

 

[XunnD]

Es ging nirgends um die Frage was C# mit C++ zu tun hat!

C# hat mit C++ nix zu tun!

Na dann muss ich mich wohl verlesen haben.

C# stammt nicht von C++ ab, C++ hatte Einfluss auf die Konzeption der Syntax von C#, so wie auch Delphi.

Die "Einflüsse" von C++ auf die Syntax von C# sind wohl erheblich stärker als die von Delphi, weshalb die Aussage, dass C# von C++ abstammt, nicht völlig aus der Luft gegriffen sein kann.

Richtig. C# nimmt einem aber hauptsächlich aufgrund der riesigen Klassenbibliotheken Implementierungsarbeit ab.

Der wesentliche Unterschied zu C++ liegt darin, das C# in Bytecode kompiliert wird, der von einer VM in Maschinencode gejitted wird. Die Laufzeit kann daher Einfluss auf die Programmausführung nehmen, was bei C++ so nicht mehr möglich ist, weil C++ direkt in CPU Instruktionen kompiliert wird.

Das eröffnet zum Beispiel Möglichkeiten in der Erhöhung der Laufzeitsicherheit, der dynamischen Optimierung der Speicherverwaltung und Easy-Reflection.

DAS sind die wesentlichen Unterschiede!

In Bytecode wird ohnehin nur kompiliert, da Plattformunabhängigkeit angestrebt wird.

Portierbarkeit
bisher: Aufgabe des Programmierers
nun: Aufgabe der VM

Ausführungsstabilität
bisher: Aufgabe des Programmierers (Stichwort: Zeigerprüfung)
nun: Aufgabe der VM

Ausführungsgeschwindigkeit (Algorithmen)
bisher: Aufgabe des Programmierers
nun: Aufgabe der VM

Dem Programmierer wird hier also auch in anderen nicht unwesentlichen Punkten erheblich entlastet.

 

[Stefan_Sch]

Na dann muss ich mich wohl verlesen haben.

Das sieht ganz dannach aus.

Die "Einflüsse" von C++ auf die Syntax von C# sind wohl erheblich stärker als die von Delphi, weshalb die Aussage, dass C# von C++ abstammt, nicht völlig aus der Luft gegriffen sein kann.

Das kann man sehen wie man will. Wenn du deine Aussage darin einschränkst das C# die Konzepte der Programmiersprachen C++ aufgreift und syntaktisch der C-Sprachfamile angehört dann ist die Aussage nicht zu beanstanden und ich bin mit dir d'accord.

In Bytecode wird ohnehin nur kompiliert, da Plattformunabhängigkeit angestrebt wird.

Das ist ein wesentliches Ergebnis das sich daraus ergibt.

Ausführungsstabilität
bisher: Aufgabe des Programmierers (Stichwort: Zeigerprüfung)
nun: Aufgabe der VM

Das hatte ich bereits erwähnt.

Ausführungsgeschwindigkeit (Algorithmen)
bisher: Aufgabe des Programmierers
nun: Aufgabe der VM

Hatte ich auch erwähnt.

Dem Programmierer wird hier also auch in anderen nicht unwesentlichen Punkten erheblich entlastet.

Natürlich. Das alles, und auch das genannte Reflection, wird durch das Bytecodeprinzip ermöglicht und das ist der Kern der Sprachen C# oder Java.

Das hat aber auch seinen Preis. Man benötigt die VM. Betriebssystemkerne wirst du mit C# also nicht programmieren können und für Embedded Systeme ist C# auch nicht konzipiert.

 

[XunnD]

Jut, dann sind wir uns ja einig.

Das alles verleitet mich zu der Aussage, dass mit C# aufgrund der zahlreichen Bibliotheken zwar zügig umfangreiche Anwendungsprogramme erstellt werden können, deren Leistungsfähigkeit aber wiederum in anderen Händen liegt (die der VM-Programmierer).
Die .NET-Anwendungen, die ich kenne, verhalten sich äußerst träge (z.B. BF2CC). Eine solche zähflüssige Usability halte ich nicht für erstrebenswert, weshalb ich .NET (und damit C#) nach wie vor ablehne. Das JIT-Compiling ist zwar gut und schön und hat sich bei Java bereits bewährt, aber die zahlreichen Bibliotheken, die jedes Mal geladen werden, lassen die Ladezeiten der Anwendungen doch stark schwach aussehen - egal ob Java oder C#.

Wie so oft erkauft man sich Vorteile mit Nachteilen.


btt: GUIs sind ohne Frameworks ein Greuel.

 

[Stefan_Sch]

Jut, dann sind wir uns ja einig.

Im Prinzip - ja.

Das alles verleitet mich zu der Aussage, dass mit C# aufgrund der zahlreichen Bibliotheken zwar zügig umfangreiche Anwendungsprogramme erstellt werden können, deren Leistungsfähigkeit aber wiederum in anderen Händen liegt (die der VM-Programmierer).

Eingeschränkt ist das richtig.

Die Ausführungsgeschwindigkeit von Algorithmen ist natürlich nicht plötzlich nurmehr die Aufgabe der VM.

Ich kann in C# einen derart grottenlangsamen Algo schreiben, das mein Program 10 Jahre und 9 Monate für die Berechnung braucht. Da wird auch die VM nicht helfen.

Die VM hat in einem sehr begrenzten Rahmen die Möglichkeit Algorithmen zu optimieren.

Der Traum der VM Programmierer ist natürlich eine Maschine die so "intelligent" arbeitet, das sie Fehler des Programmieres wegoptimiert.

Das ist aber nachwievor ein Wunschtraum und der Grund warum C++ weiterhin bei den großen Spitzenanwendungen vorne liegt. Ob Firefox oder SQL Server, diese Anwendungen sind hochperformant und in C++ geschrieben, weil man mit C++ volle Kontrolle hat und bis zum Abwinken optimieren kann.

Die .NET-Anwendungen, die ich kenne, verhalten sich äußerst träge (z.B. BF2CC). Eine solche zähflüssige Usability halte ich nicht für erstrebenswert, weshalb ich .NET (und damit C#) nach wie vor ablehne.

Ja, wie im Leben auch, hat alles seine Vor- und Nachteile.

Das JIT-Compiling ist zwar gut und schön und hat sich bei Java bereits bewährt, aber die zahlreichen Bibliotheken, die jedes Mal geladen werden, lassen die Ladezeiten der Anwendungen doch stark schwach aussehen - egal ob Java oder C#.

Richtig.

Wie so oft erkauft man sich Vorteile mit Nachteilen.

Jetzt hast du meine Worte vorweggenommen.

btt: GUIs sind ohne Frameworks ein Greuel.

Auch richtig. Dreimal darfst du raten wieviel Code das erste Windows GUI Programm hatte, was nur ein leeres Fenster anzeigte?

Das war Horror pur!

 

[roker002]

C# hat mit C++ nix zu tun! Du stellst dich gerade so hin, als ob man von C++ auf C# umsteigt und quasi upgradet.

Das sind zwei vollkommen verschiedene Sprachen. C# basiert auf einer Plattform, nämlich .NET, während C++ direkt in Maschinencode kompiliert wird.

Einen GUI Builder gibt es auch für C++ unter Qt. Das ist für die Klickibunti-Fraktion hier im Forum.

Die MFC werden noch sehr lange existieren, das hat Microsoft öffentlich bestätigt. Auch wenn die MFC schon sehr alt sind, die Bibliothek wird zwar weiterhin weiterentwickelt, aber das Konzept stammt nunmal aus den 90igern.

Die gesamte CLR ist übrigens in C/C++ geschrieben. Genauso, wie der C# Compiler.

ich habe nicht gesagt dass C# ein upgrade zu c++ ist. Als ich mit C++/MFC Programmiert habe, was recht gut geht, musste ich feststellen das es nur sehr schlechen support zu bibliotheken von MS gegeben hat. Musste sehr viel erstmal selbst rausfinden. C# hat einfach den Vorteil dass es sehr gut aufgebaut ist. Nebenbei gibts es paar neue funktionalitäten die C++ garnicht hat und erst D-Sprache ermöglich.

man muss halt wissen was man programmieren will. Sollte es für alle BS gleich laufen, würde man C++ nehmen, oder mit umstand MS Bibliotheken nachinstallieren

Bin eignetlich bisschen vom thema abgekommen. Naja mit MS tut man sich mit GUI builden auch ganz gut. weiss nicht wie es im Qt aussieht, vielleicht auch besser. Man sollte einfach mal ausprobieren wie es ist.

 

[Stefan_Sch]

ich habe nicht gesagt dass C# ein upgrade zu c++ ist. Als ich mit C++/MFC Programmiert habe, was recht gut geht, musste ich feststellen das es nur sehr schlechen support zu bibliotheken von MS gegeben hat.

Der Support für die MFC ist sehr gut. In den Neunzigern und zu Beginn der 2000 waren Anwendungen, die die MFC nutzten noch Standard.

Das Problem an den MFC ist, sie ist alt und es ist teilweise grausam sie zu verwenden, weil sie eben alt ist und die Objektorientierung damals schlecht implementiert wurde.

Natürlich ist die MSDN Doku für .NET auch eine ganz andere Liga, als die für die MFC.

Nebenbei gibts es paar neue funktionalitäten die C++ garnicht hat und erst D-Sprache ermöglich.

Es gibt nichts in C#, was man mit C++ nicht nachbilden könnte. D.h. alles was mit C# programmierbar ist, ist auch mit C++ programmierbar und mehr noch.

C# hat natürlich eingebaute Sprachkonstrukte, wie LINQ, was es so bei C++ nicht gibt und die Produktivität erhöht. Für C++ muss man sich dafür erst die notwendigen Bibliotheken zusammensuchen.

Auch hat C# 3.0 viele weitere neue Konstrukte eingeführt. Lambda Ausdrücke sind ein Beispiel. Diese wird es in C++ erst mit dem neuen Standard C++0x auch geben. Man muss auch sehen das hinter C# mit Microsoft der größte Softwarekonzern der Welt steckt. Die geben nunmal richtig Gas und haben auch das dafür notwendige Kleingeld.

.NET hat meiner Ansicht nach Java schon überholt. Microsoft könnte Java ausknocken, wenn sie ihre Plattform auch für andere Betriebssysteme freigeben würden. Mit Mono gibt es immerhin einen Ableger für Linux, der ist aber nicht offiziell.

Umgekehrt erlaubt C# z.B. keine mehrfache Vererbung. Auch unterscheiden sich die Sprachen in ihren Paradigmen. C# gestattet keine prozedurale Programmierung.

Diese beiden Sprachen sind einfach unterschiedlich!

Natürlich ist es angenehm in C# zu programmieren. Die FCL hat Klassen bis zum Abwinken. Da kann man von E-Mail versenden bis Ping alles finden. Für C++ gibts nichtmal eine offizielle Socketbibliothek. Stattdessen muss man direkt auf die OS API zugreifen oder eine Lib nutzen, die das macht.

Man darf auf den neuen Standard C++0x gespannt sein. Er wird richtig reinhauen und C++ auf die nexte Ebene heben!