GUI C++

[SGT.Hawk]

Moin Leute,
habe gerade Semesterferien, muss mir mal wieder ws neues beibringen, da es zu langweilig wird.Da ich schon SWING/SWT gemacht habe und C++ einigermassen kapiert habe, will ich mal da was versuchen.:biggrin:
Welches Frameworks könnte man nehmen?
.NET/WINAPI/MFC
Achaj, der neueste Schrei soll,so habe ich vom Kumpel gehört wxwidgets sein.
Was meint ihr, was bringt Spass.

[Coda]

wxWidgets. Ist auf jedenfall das Beste was es frei gibt (ansonsten wäre es Qt, aber das gibts nur unter GPL-Lizenz).

Der neuste Schrei ist das aber eigentlich nicht, das gibts schon seit 92 ;)

Auf gar keinen Fall MFC und direkt Win32 ist sowieso nur was für Sadisten.

[Trap]

Winapi und MFC ist beides Folter. Sag ich aus Erfahrung.

QT und wxWidgets dürften ganz ok sein, hab allerdings bei beidem nicht mehr gemacht als Beispielcode zu lesen.

[Coda]

Vor allem ist es mit wxWidgets auch noch halbwegs portabel. Hat auch was für sich.

[SGT.Hawk]

Portabilität ist im Prinzip in keiner Sprache gegeben, sag ich mal aus Erfahrung,auch nicht in Java, bis auf Kleinigkeiten.
Garbage Collection muss man trotzdem selber machen, auch bei den Widgets oder?Ich dachte, wenn man mit der WINAPI oder so mal anfängt, versteht man die Kniffe und kleine Fehler schneller.

[Gast]

Betreffend Win32 API muß ich meinen Vorrednern einerseits Recht geben: für den längerfristigen Alltagseinsatz ist die grausam. Aber: mit der zu arbeiten ist sehr hilfreich, wenn man verstehen will, wie die GUI unter Windows funktioniert. Mit Dingen wie der WinMain, mit Windows Procedures, Windows Messages und Ereigniswarteschleifen sollte man zumindest mal hautnah zu tun gehabt haben, wenn man die dann verstanden hat kann man immer noch zu visuellen Tools übergehen.

Ok ok, vielleicht ist mein vergleichsweise positives Verhältnis zur Win API auch dadurch begründet, daß ich lange Zeit stets den Begriff der objektorientierten Programmierung immer im Zusammenhang mit der VCL von Delphi gesehen habe. Ich dachte, Objekte seien immer grafische Objekte wie in der VCL. Als ich dann eines schönen Tages erfuhr, daß OOP eigentlich etwas davon ganz und gar unabhängiges ist, wollte ich, um mich von meinen bisherigen Vorstellungen loszulösen, beides mal getrennt voneinander betrachten: OOP ohne GUI, GUI ohne OOP. Und für letzteres kam mir die Win32 API gerade recht.

Falls du schwankst zwischen Win API und MFC: nimm Win API. Die MFC ist zwar noch relativ API-nah (die Entsprechungen zwischen API-Handles und MFC-Klassen ist unübersehbar), in einigen zentralen Aspekten aber schon allzu high-level: du bekommst z.B. in der Regel keine Window-Procedure mehr zu Gesicht, stattdessen gibt es einen MESSAGE_MAP. Wenn man nicht weiß, daß da irgendwo ne Window Procedure hinter gekapselt ist, verleitet der einen nur zu falschen Vorstellungen. Da nehm ich noch lieber den Objektinspektor einer visuellen IDE, da erkennt man wenigstens sofort daß der nur ein Front End ist.

[Coda]

SGT.Hawk[/POST]']Portabilität ist im Prinzip in keiner Sprache gegeben, sag ich mal aus Erfahrung,auch nicht in Java, bis auf Kleinigkeiten.
MFC und Win32 sind auch wenn man sich auf Windows beschränkt eine absolute Krankheit im Gegensatz zu wxWidgets.

SGT.Hawk[/POST]']Garbage Collection muss man trotzdem selber machen, auch bei den Widgets oder?
Die Widgets löschen zumindest ihre Subwidgets automatisch.

SGT.Hawk[/POST]']Ich dachte, wenn man mit der WINAPI oder so mal anfängt, versteht man die Kniffe und kleine Fehler schneller.
Man kann sichs mal antun (hab ich auch), aber dann nur ums zu verstehen und nicht für nen richtiges Projekt. Da wirst echt dumm davon.

[SGT.Hawk]

Ja, so habe ich es mir auch gedacht, später dann schön mit wxwidgets.
Übrigens, wens intressiert, hier ein Tutorial:
http://www.winprog.org/tutorial/

[Matrix316]

Gast[/POST]'] OOP ohne GUI, GUI ohne OOP. Und für letzteres kam mir die Win32 API gerade recht.

Wobei Win32 auch eigentlich teilweise fast schon manchmal "Objektorientiert" ist. Z.B. bei sowas:

wndClass.cbSize=sizeof(WNDCLASSEX);
wndClass.style=CS_HREDRAW|CS_VREDRAW;
wndClass.lpfnWndProc=WndProcedure;
wndClass.cbClsExtra=0;
wndClass.cbWndExtra=0;
wndClass.hInstance=hInstance;

[Gast]

Ich stimme dir zu das WinAPI objektorientiert ist, aber dein Code zeigt nichts davon.

[del_4901]

Gast[/POST]']Ich stimme dir zu das WinAPI objektorientiert ist, aber dein Code zeigt nichts davon.
da steht Class .... muss doch objektorientiert sein *hust*

[Kabelsalat]

Ein nicht unwesentlicher Teil der WinAPI beruht eben auf COM und das ist sehr wohl objektorientiert.

[Demirug]

Die Win32 API nutzt eine ADT Variante. Das ist zwar noch nicht ganz OOP aber der direkte Vorläufer. Wer schon mal COM mit C programmiert hat kennt das Prinzip.

[Gast]

Matrix316[/POST]']Wobei Win32 auch eigentlich teilweise fast schon manchmal "Objektorientiert" ist. Z.B. bei sowas:sagen wir mal so: Microsoft verwendet in der API munter Begriffe aus der OOP, allerdings ohne sich sonderlich um deren dortige Bedeutung zu scheren.
Z.B. ist deine WNDCLASS überhaupt gar keine Klasse, sondern eine struct.

Meiner persönlicher Eindruck ist, daß Microsoft sich mit der API den Anschein von Objektorientierung geben wollte - und weil ihnen das außer vielleicht Charles Petzold niemand abgekauft hat, haben die dann irgendwann kurzerhand behauptet, ihnen sei immer klar gewesen daß die Win32 API nicht OO ist, und sie hätten schon lange vorausschauend erkannt, daß eine OO Schnittstelle her müsse, und deswegen die MFC rausgebracht.

[Gast]

Kabelsalat[/POST]']Ein nicht unwesentlicher Teil der WinAPI beruht eben auf COM und das ist sehr wohl objektorientiert.die Win32 API beruht auf COM?? Ist es nicht eher umgekehrt? Daß COM eine ähnlich wie MFC, ATL, OLE, .NET, ... auf der API aufbauende Bibliothek ist?

[del_4901]

Gast[/POST]']sagen wir mal so: Microsoft verwendet in der API munter Begriffe aus der OOP, allerdings ohne sich sonderlich um deren dortige Bedeutung zu scheren.
Z.B. ist deine WNDCLASS überhaupt gar keine Klasse, sondern eine struct.

Meiner persönlicher Eindruck ist, daß Microsoft sich mit der API den Anschein von Objektorientierung geben wollte - und weil ihnen das außer vielleicht Charles Petzold niemand abgekauft hat, haben die dann irgendwann kurzerhand behauptet, ihnen sei immer klar gewesen daß die Win32 API nicht OO ist, und sie hätten schon lange vorausschauend erkannt, daß eine OO Schnittstelle her müsse, und deswegen die MFC rausgebracht.

eine struct ist eine public class ...

[SamStone]

eine struct ist eine public class ...
Aber nur in C++, nicht in C.

[zeckensack]

eine struct ist eine public class ...WNDCLASS hat keinen Konstruktor. Also Wayne.

[Gast]

eine struct ist eine public class ...die WNDCLASS hat aber nur Datenmember. Eine Klasse im Sinne der OOP sollte aber auch ein paar Methoden haben. Etwa wie die CWnd-Klasse der MFC.

[tokugawa]

Die "Class" im Begriff Window Class bezieht sich überhaupt nicht auf das Sprachkonstrukt einer "Klasse". Dort geht es um den Begriff "Klasse" wie er auch in der natürlichen Sprache verwendet wird. Also wird eigenltich nicht Objektorientiertheit suggeriert, da man mit "Window Class" nicht eine Klasse im OOP-Sinn meint, sondern eine Fensterklasse (also einen bestimmten Fenstertyp den man registriert).

Dass es Teilkongruenzen mit dem OOP-Begriff einer "Klasse" gibt, liegt daran dass in der OOP der Begriff "Klasse" ja genau für solche Dinge gedacht ist: Gruppierung von Attributen und Verhalten von Objekten gleicher Art.

Leute, das Wort "Klasse" wurde nicht erst durch OOP erfunden... :tongue:

Und ich sehe ein struct bzw. eine methodenlose Klasse ebenfalls als Klasse an. Wer sagt dass eine Klasse unbedingt Methoden haben muß (zumal es in vielen OOP-Sprachen gar kein reines "Daten-Struct" gibt).


Zum Thema selbst:
Das Problem hatte ich auch bei meiner Engine, da ich auch gute Content-Tools dafür machen wollte, und die eine GUI brauchen. Letztendlich hab ich mit dann für .NET 2.0 entschieden im Zusammenhang mit C++/CLI - dort kann ich meine native Library reinlinken und verwenden (fast) ohne Probleme, auch wenn der GUI Designer in Visual Studio 2005 für C++ Projekte ziemlich langsam ist (speziell nach Codeänderungen).

Mit reiner WinAPI (darin hab ich meine Game-Application gemacht) und MFC hab ich Erfahrung. Ist tatsächlich für Masochisten, aber sicher auch nicht schlecht wenn man's zumindest kennt. Qt hat mir lizenztechnisch nicht gefallen, und wxWidgets hab ich mir angeschaut und war eigentlich abgeschreckt davon, dass es eigentlich in vielen Teilen der MFC nachempfunden ist, aber wenn Coda schreibt dass wxWidgets viel besser ist, schau ich's mir vielleicht wieder an.

Für MFC würd ja die enorme Menge an Third-Party-Code sprechen, etwa Libraries wie Prof-UIS oder BCGControlBar, mit denen die Anwendungen ein professionelles Look-And-Feel im Stil von Visual Studio oder MS Office bekommen (das wiederum der Grund war warum ich mich gegen GTK entschieden hab).