C++ Eclipse GUI Programmieren

[Yogi666]

Hallo,
Ich nutze sein einiger Zeit Eclipse um C/C++ zu lernen.
Da ich die grundsätzlichen Sachen in C++ mittlerweile gut kann, wollte ich mal anfangen von der Konsole wegzukommen.

Ich suche eine Möglichkeit GUI zu programmieren für Windows in Eclipse. Ich hab bereits Google bemüht und bin dabei auf "Visual Editor" gestoßen, was jedoch leider nur für Java ist scheinbar.

wxwidgets fand ich auch.
Andere Quellen sagen, dass man sowas lieber nur mit Visual Studio machen sollte.

Hat jemand Erfahrungen mit gui programmieren in eclipse?
Bin für jede Hilfe dankbar
gruß
yogi

 

[0xffffffff]

Nimm Qt, damit tust Du dir gerade bei C++ einen sehr großen Gefallen: http://qt.nokia.com/products

 

[1668mib]

Naja du musst dich zuerst eben für ein Framework entscheiden, mit welchem du arbeiten willst...

Ein solches Framework könnte MFC oder .net sein (beides von Microsoft, von ersterem würde ich bei einem Einsteiger abraten), aber es gibt auch andere wie Qt... für welches du dich entscheidest, ist deine Sache.

Solltest du dich für .net entscheiden:
a) mir mal C++/CLI anschauen, einen C++-Dialekt von Microsoft für .net
b) direkt C# statt C++/CLI (weil ich letzteres eigentlich grausam finde)
und dazu eben am besten das entsprechende Visual Studio Express benutzen - die neuen 2010er-Version müssten in einigen Tagen erscheiinen...

 

[0xffffffff]

Noch als Hinweis, Qt bringt seinen eigenen Designer mit. Bezüglich C++/CLI, wer tut sich bitte sowas an? C++ nimmt man ja eher wegen der Geschwindigkeit & Ressourcensparenderem Programmieren, da keine riesige Runtime benötigt wird, und weniger weil es eine elegante Sprache ist. Wenn man sich schon für .Net entscheidet, kann man auch lieber zu C# oder gar etwas exotischerem wie IronPython greifen.

wxWidgets ist altbacken und hat auch einige schwächen, z.B. wenn du irgendwelche Elemente/Widgets nutzt die es auf einer anderen Plattform garnicht nativ gibt.

Qt ist wunderbar designed und bringt noch jede Menge andere sehr nützliche Sachen mit die man so als C++ programmierer gebrauchen kann. Außerdem ist es ja seit einiger Zeit LGPL

 

[1668mib]

@0xffffffff: C++/CLI tun sich glaub nur Menschen an, die auf Schmerzen stehen :-)

 

[Yogi666]

Super dann probier ich mal die qt libaries in eclipse einzubinden.
die api davon sieht auch ganz nett aus.

Ergänzung (7. April 2010)

Ich bin beim lesen auf der api auf folgendes gestoßen:

"Many of these Qt features are implemented with standard C++ techniques, based on inheritance from QObject. Others, like the object communication mechanism and the dynamic property system, require the Meta-Object System provided by Qt's own Meta-Object Compiler (moc)."

Öh, brauch ich das unbedingt? Oder kann ich einfache Sachen auch ohne das bauen?

 

[problemlöser64]

Nee ne, völliger Quatsch...

Wer .NET-programmieren will, der nimmt c# oder VB! Niemals C++.

Wer schon den C++ Syntax kennt, der ist ambesten mit Visual C++ beraten.
Microsoft Visual Studios C++ Express Edition: Beste Entwicklungsumgebung dafür
von Microsoft (Express ist kostenlos)

Das hat dann den Vorteil, dass der Anwender keine Framework installieren muss!
Formular-Anwendungen kannst du auch machen, mit CreateWindowEx(...) oder so.
Du kannst auch fertige Dialogfelder aus den Resorcen der Anwendung laden, da tust du dir leichter.

Bitte beachten: C++ ist nicht gleich Visual C++. C++ beschreibt nur den Syntax. Mit was schreibst du denn, wenn ich fragen darf?

 

[badday]

Also man muss hier schon unterscheiden: Qt ist sehr mächtig, bietet sehr viel und ist daher auch etwas komplex.
Wenn du nur für eine Plattform programmierst und deine Programme nicht von gewissen Features profitieren würden, ist wohl Visual C++ (bzw. wie von problemlöser64 geschrieben C# oder VB) die bessere Wahl.
Es kommt halt darauf an, was du machen willst, was du kannst und welche Anforderungen du erfüllen musst.

Gruß,

badday

 

[problemlöser64]

Das stimmt schon. Wer einfach mal schnell gute und schöne Anwendungen machen möchte nimmt am Besten c#.NET oder VB.NET. (ich nehme immer c#).
Java soll da auch ganz gut sein. Nur benötigt der Anwender halt immer die Laufzeitumgebung, also wer schon VC++ programmiert, beabsichtigt wahrscheinlich damit, dass die Anwendungen keine Laufzeitumgebun brauchen.
Ansonsten wäre es auch echt nicht sinnvoll, sich das komplizierte VC++ anzulernen.

Ergänzung (7. April 2010)

Noch kleiner Vermerk:
Kann mal jemand mir sagen, ob Eclipse überhaupt V I S U A L C++ ist oder was anderes?

 

[darkarchon]

@problemloeser64: Und .net ist keine Laufzeitumgebung?
Die ganzen .net Sachen basieren auch auf einer VM, nur dass diese nur unter Windows laeuft.

 

[problemlöser64]

VB.NET und c#.NET basieren eben auf die .NET Framework LAUFZEITUMGEBUNG.
Jave auf die Java-LAUFZEITUMGEBUNG
Es gibt sogar C++.NET (eher ungewöhnlich)
Nur VC++ basiert auf keiner Laufzeitumgebung.
Danke für den Hinweis, habe ich mich wohl etwas undeutlich ausgedrückt.

 

[asdfman]

C und C++ haben jeweils ihre Laufzeitumgebungen. Nämlich die Standardbibliotheken, ohne die Programme in diesen Sprachen in aller Regel nicht laufen (denn der Code, der main() aufruft befindet sich dort).

 

[problemlöser64]

Ich verstehe nicht ganz, was main() aufrufen soll. Das int main(char[] parameter)
deklariert die Main-Methode, wenn du dieses Main meinst. Das ruft nichts auf.
Ich nehme jetzt mal als Beispiel C++, bei C wird es wahrscheinlich genauso sein, weiß ich nicht so genau.

C++ verwendet Haederdateien, die in die Anwendung hineinkompiliert werden. Die Anwendung ist damit vollständig und braucht keine weiteren Laufzeitumgebungen mehr. Ich würde die Haederdateien nicht als Laufzeitumgebung bezeichnen aber ist mir egal. Die Haeder rufen dann in der Anwendung Standart-Windows-Bibliotheken auf, welche ich auch nicht als Laufzeitumgebung bezeichnen würde. Oder rufen die noch mehr auf? Ganz sicher bin ich mir auch nicht, aber ziemlich sicher.

 

[NullPointer]

@asdfman: Es besteht aber ein wesentlicher Unterschied zwischen einer Standardbibliothek wie libc und einer Laufzeitumgebung wie JRE oder .NET. Im ersteren Fall handelt es sich eben "nur" um eine Funktionsbibliothek, ausgeführt wird der Code direkt auf der Hardware - und nicht auf einer virtuellen Maschine wie etwa bei JRE.

 

[0xffffffff]

Die main()-Funktion ist einfach der Einstigespunkt für das Betriebssystem wenn es ein Programm ausführt. Und header werden auch nicht einkompiliert.

Header werden (idR) ausschließlich zur Deklaration von Funktionen, Variablen etc... verwendet die man in anderen Programmodulen ggf. nutzen möchte oder muss. Wenn der Compiler deine C oder C++ Dateien Abarbeitet und auf einen Funktionsaufruf gerät und die Funktion dem Compiler nicht bekannt ist wird der dir was husten.

Der Compiler weiß nichtmal wo die Funktion liegt, was ihm auch total egal sein kann. Der will einfach vorher von dir Wissen dass es das überhaupt gibt, was Du da gerade aufrufst. Der Funktionsaufruf wird erst zum Schluss durch den Linker aufgelöst, indem er dort die entsprechenden Sprungadressen setzt. Denn nur der Linker weiß letztendlich die Position der eigentlichen Funktion (als relative Adresse, die Absoluten Adressen sind erst nach Programmstart bekannt wenn Speicher alloziert wurde )

* Der Compiler setzt nur Platzhalter.
* Der Linker ersetzt die Platzhalter bei statischen (ins programm eingebundene) Funktionen die relativen Sprünge zu diesem im eigentlichen Assembly. Bzw bei dynamischen Funktionsaufrufen zur Laufzeit (aus DLL's / SO's) legt er Infos ab in welcher DLL/SO er die Funktionen erwartet und welche Signatur diese haben. Daher auch der name "Dynamic Link Library"

Bei kleineren Funktionen _kann_ der Compiler auch Funktionen "Inlinen", d.h. er ersetzt den Funktionsaufruf direkt durch den eigentlichen Funktionscode, aber das geht erstmal zuweit, denke ich.

Header Dateien sind sogesehen nichts anderes als "Forward Declarations".

 

[problemlöser64]

Ok, der eigentliche Compiler ist einer von drei Schritten, welche beim Erstellen ausgeführt werden:

1.Präprozessor
2.Compiler
3.Linker

Doch Umgangssprachlich sagt man zu allen drei auch Compiler, obwohl das eigentlich nicht ganz korrekt ist.

Die Haederdateien sind übrigens vorkompiliert. Die sind nur für den Linker wichtig, der flickt dann den selbst geschriebenen Code (der bis da hin kompiliert wurde) mit den Haedern (die schon bei der IDE-Installation kompiliert auf die Festplatte kopiert werden) zusammen zu einer Anwendung.

Ergänzung (7. April 2010)

Zum Inlinen:
Ob geinlinet wird oder nicht entscheidet oft der Präprozessor (Optimierer) für den Compiler(der dann inlinen tut). Doch ist es finde ich besser, wenn der Präprozessor da nicht entscheidet, sondern der Programmierer selbst mit dem Schlüsselwort "inline".

 

[0xffffffff]

Wie das gemurkse mit den Precompiled Headern funktioniert weiß ich nicht. Aber die normalen Header haben rein garnichts mit dem Linken zu tun. Wenn der Linker irgendeine referenzierte Funktion nicht finden kann, weil beispielsweise eine Bibliothek vergessen wurde, bekommst du ein Linker-Error der dich eben darauf hinweißt.

Und der Präprozessor hat auch nichts mit dem Compiler-Seitigen Inlinen zu tun. Der Präprozessor ist genaugenommen ein strunzdummer Textersetzer der bedingte Ausdrücke und eins, zwei weitere Dinge unterstützt. (#if...)

Man misshandelt den Präprozessor oft mittels Makros dazu quasi zu inlinen, indem man z.B. sowas schreibt:

#define NOT_NULL(pointer) if (pointer == NULL) exit();

Der Präprozessor macht nun nichts anderes als _vor_ dem Kompilieren "NOT_NULL(var)" durch das in der selben Zeile stehenden zeug textuell zu ersetzen.

Der Compiler kann selbst inlining vornehmen, wo er es für sinnvoll enthält. Außerdem kann man den Compiler einen Hinweis geben (und nicht zwingen) die als inline markierte Funktion doch bitte zu Inlinen. Er hat sich aber nicht daran zu halten. Darum eben oft der Präprozessor-Hack den man aber auch tunlichst unterlassen sollte, weil das zu sehr schwer auffindbaren Bugs führen kann. Beispielsweise:

#define max(a,b) ((a<b)?b:a)
max(a++,b++);

Dort werden a und b nämlich zweimal inkrementiert. Viel spaß dabei sowas zu finden

Makros sind oft böse und man sollte sie vermeiden. Das selbe gilt für #defines für konstanten. Diese tauchen dann beim Debuggen einfach als Zahl auf und haben kein zugewiesenes Symbol. Beispiel:

#define D_RADIUS 12
const int I_RADIUS = 12;

Wenn du nun debugst, wirst du bei dem Define einfach irgendwo ne "12" sehen, wo kommt die her? Was bedeutet die? Bei dem konstenten Integer aber immerhin auch noch dessen Symbol "I_RADIUS" angezeigt oder als Dump.

Zudem der Präprozessor kein Optimierer, sondern einfach ein Hilfsmittel für bedingtes Compilieren Wie gesagt, das teil ist im Grundegenommen ein etwas erweitertes string_replace().

 

[problemlöser64]

Nun ja, von IDE zu IDE unterschiedlich. Im Visual C++ Compiler zwingt ein "inline" zum inlinen, ausserdem ist der Präprozessor nicht nur für die Anweisungen hinter "#" zuständig sondern optimiert auch. Wie gesagt, von IDE zu IDE verschieden. Aber immerhin gibt es wohl doch noch Leute außer mir (Das ist eine Hyperbel!), die es interressiert, was beim Klick auf das "Erstellen und Ausführen Zeichen" eigentlich passiert. Vielen Dank für deine Anmerkung.

 

[Woey]

ausserdem ist der Präprozessor nicht nur für die Anweisungen hinter "#" zuständig sondern optimiert auch.

z.B. ?

 

[asdfman]

Ich verstehe nicht ganz, was main() aufrufen soll. Das int main(char[] parameter)
deklariert die Main-Methode, wenn du dieses Main meinst. Das ruft nichts auf.

Wenn man ein Programm in C oder C++ schreibt, geht man gemeinhin davon aus, dass es quasi an der Stelle,
wo main seine main() Funktion deklariert anfängt.
Das ist aber nicht so. Wenn man ein normales C-Programm (also eins das die Standardbibliothek benutzt und
eine main()-Funktion besitzt) übersetzt, wird ganz an den Anfang der ausführbaren Datei eine Funktion aus
der Standardbibliothek gesetzt, die bei mir crt0() heißt. Der genaue Name mag von Plattform zu Plattform
verschieden sein. Diese Funktion führt erst einmal grundlegende Aktionen aus, die der Ausführung des Programms
vorgenommen werden müssen. Danach springt das Programm erst zu main().

Header werden, wie bereits gesagt, natürlich nicht kompiliert. Der präprozessor ist in der Tat nichts weiter,
als ein einfacher Textersetzer. Was jemand mit dem Schlüsselwort inline meint, weiß der nicht. Optimierungen
nimmt er natürlich auch keine vor.