Unterschiede zu MFC
-
Stromberg schrieb:
Also wäre es für jemand wie mich, der C++ neuling ist und mit C nichts am Hut hat sinnlos die WinAPI zu lernen.
Genau.
Stromberg schrieb:
Aber was würdest du mir dann empfehlen wenn ich Fensterchen programmieren will?
1. Falsches Forum. Für sowas haben wir ein allgemeines GUI-Forum. Hier wird dir jeder Win32-Programmierer natürlich Win32API empfehlen. Biste in einem Mercedes-Forum, wird dir niemand der MB-Fahrer einen BMW empfehlen.

2. Ich kann und will dir nichts empfehlen. Ich habe die GUI-Übersichtstabelle erstellt, damit sich jeder selbst entscheiden kann, was für ihn am sinnvollsten ist. Wenn du eine Empfehlung brauchst, mußt du deine wichtigsten Kriterien nennen, damit ich und andere dir eine Empfhelung geben können.Stromberg schrieb:
QT ist doch das schöne, das ich den Code dann unter Window sowie unter Linux compilieren kann?
Und damit entfallen Win32-API und MFC definitiv! Diese sind 100% Windows-Only.
Stromberg schrieb:
Was soll ich benutzen das in 2-3 Jahren nicht schon wieder veraltet ist? Was hat Zukunft und ist geeignet für mich?
Dankeschön schon mal im Voraus.Was ist veraltet? Bezogen auf was? Das was meistens veraltet ist, ist das Design einer Library (wie Klassen aufgebaut sind u.ä.). Moderne Libraries gibts für C++ nur wenige. Die etablierten wie wxWidgets, MFC, Qt usw. sind veraltet, richtig. Aber sie werden auch in 2-3 Jahren noch laufen. Manchen Programmierern ist das egal, ob eine Library ein veraltetes Design hat. Gut. Andere wollen das nicht mehr sehen (wie ich), und benutzen dann lieber weniger oder noch nicht etablierte aber moderne Libs. Da fällt mir spontan VCF ein. Kannst du aber alles in meiner Übersicht nachlesen oder geh in das GUI-Forum und stelle da deine genaueren Anforderungen. Hier ist das alles Off-Topic.
Kann ein Mod diesen Thread ins GUI-Forum verschieben?
-
Ähm das ich nichts falsch verstehe, mit QT,MFC und WinAPI lassen sich doch nicht nur Fensterchen coden sondern auch so Dinge wie Netzwerk;Ordner etc.; kann man da auch noch buntere Dinge machen oder z.B. ein 3D Modell reinladen (hab da grad zwar kein Interesse dran aber würde mich interessieren)oder muss man da dann DirectX verwenden?
PS: Ich geh jetzt davon aus das dass hier verschoben wird. Wenn nicht dann werde ich einfach meinen nächsten Beitrag ins GUI-Forum schreiben.
-
Ähm das ich nichts falsch verstehe, mit QT,MFC und WinAPI lassen sich doch nicht nur Fensterchen coden sondern auch so Dinge wie Netzwerk;Ordner etc.; kann man da auch noch buntere Dinge machen oder z.B. ein 3D Modell reinladen (hab da grad zwar kein Interesse dran aber würde mich interessieren)oder muss man da dann DirectX verwenden?
Jede Library verfolgt ein anderes Ziel. Es gibt Libraries wie Qt und MFC die eher Frameworks sind, als Libraries. Und ja, diese beiden Beispiele bieten mehr als nur Fenster an, z.B. Netzwerk. Obwohl der eigentliche Grund dieser Libs GUIs sind. Aber, warum ist das so? Der Grund ist, das diese schon sehr lange auf dem Markt sind und damals gab es für C++ z.B. keine platformübergreifenden Netzwerk-Libs. Also haben Qt, MFC usw. eigene Netzwerk-Klassen entwickelt. Wenn jemand heute eine C++-GUI-Lib entwickelt, wird er wahrscheinlich keine Netzwerk-Lib mehr da rein packen. Weil es heute schon welche gibt, die sogar wahrscheinlich in den nächsten ISO-C++ TR2 rein kommen.
Wie gesagt, viele Libs sind sehr alt (das heißt nicht, das sie nicht weiter entwickelt werden!) und deshalb decken sie mehr als nur das Thema GUI ab. Diese werden es auch irgendwann schwer haben, wenn der nächste C++-Standard erscheint. Z.B. hat TR1 schon Regex, etwas was in vielen GUI-Libs mit dabei ist. Ist jetzt aber völlig sinnlos, wenn z.B. Qt mit einem Regex-Feature wirbt, wenn bald jeder Compiler eh Regex im Lieferumfang haben wird. Genau das gleiche mit Netzwerk: es ist nicht unwahrscheinlich, das asio in den C++ Standard TR2 rein kommt. Dann wird es wieder ein Argument weniger für Qt's Netzwerk-Klassen geben.
Wenn Du 3D-Grafik machen willst, kannst DirectX oder OpenGL nehmen. Oder gleich eine 3D-Engine, die die Arbeit mit 3D um einiges vereinfacht. Es gibt zu jedem Problem und Theme unter C++ seeeehr viele Libraries, Frameworks und Engines. Das muß dir bewusst werden, das man sich da selber auch erstmal informieren muß. Alleine an 3D-Engines gibt es so viele, das man nicht sagen kann: benutze nur diese eine 3D-Engine.
-
Darum gibt es hier in WinAPI Forum auch so wenig beiträge. Keiner nutzt sie.
-
So siehts aus^^
-
winapi ist nützlich, aber nur für spezielle sachen.
ein mittelgrosse windowsanwendung mit einigen fensterchen, dialogboxen und controls da drin möchte ich nicht coden. das ist viel zu aufwendig. da ist man mit fertigen frameworks besser dran (auch wenn's nur mfc ist)...
andererseits lernt mal viel über die funktionsweise des windowmanagers usw., wenn man alles in 'pure winapi' macht

-
oder man macht es so wie viele es machen und ich ebenfalls - man kalselt sich die ganzen winapi elemente in klasse - braucht die nur noch erben bzw subclassen schon kann man die benutzen ohne gross viel coden zu muessen
ich hab mitlerweile alle steuerelemente eines fensters gekapselt das ich nur noch ein sehr simples create mit positionen aufrufen muss und schon kann ich damit arbeiten
einfach - schnell - zuverlaessig - klein #gg
-
Ja, aber dieses "Ich kappsel mir das jetzt selbst" kann sich nicht jeder leisten. Warum machst du das? Weil es dir Spaß macht? Ich pers. gehe in der Software-Entwicklung nicht immer von Spaß aus. Es gibt genug Leute, die mit Programmierung Geld verdienen müssen. Da kannst du in einem Projekt nicht erst anfangen und die Win32-API kapseln. Das ist Zeit, die man anders und besser zu Geld machen kann. Deshalb verstehe ich nicht, warum sich hier einige angepisst fühlen, wenn ich sage, das nur die wenigsten Win32API direkt benutzen. Die meisten benutze Wrapper wie MFC, wxWidgets, VCL und VCF. (es gibt noch viel mehr auf dem Markt)
Klar, aus Spaß mache ich auch Dinge, die ich beruflich nicht machen würde. Auch viele Leute, die Programmierung zum Hobby haben, kapseln nicht erst die Win32-API. Sondern wollen z.B. einfach ein Produkt (was weiß ich, z.B. Vereinsveraltungs-Programm) programmieren. Und sich nicht mit Win32-API rumkrepeln. Nein, da wird wxWidgets genommen und ab gehts mit der eigentlichen Arbeit (dem eigentlich Ziel).
Also, man sollte nicht so tun, als ob für jeden die Win32-API sinnvoll ist und nicht gleich beleidigt sein.

-
Artchi schrieb:
Ja, aber dieses "Ich kappsel mir das jetzt selbst" kann sich nicht jeder leisten. Warum machst du das? Weil es dir Spaß macht?
Japs, ich machs aus spass nebenbei, sodass ich das sobald ich es fertig hab einfach fuer meine projekte benutzen kann
Artchi schrieb:
Ich pers. gehe in der Software-Entwicklung nicht immer von Spaß aus. Es gibt genug Leute, die mit Programmierung Geld verdienen müssen. Da kannst du in einem Projekt nicht erst anfangen und die Win32-API kapseln. Das ist Zeit, die man anders und besser zu Geld machen kann.
Auf arbeit benutz ich MFC, das eine hat mit den anderen ja nicht unbedingt was zu tun, also software entwickler ist man nichtmal in der sprache gebunden
Artchi schrieb:
Deshalb verstehe ich nicht, warum sich hier einige angepisst fühlen, wenn ich sage, das nur die wenigsten Win32API direkt benutzen. Die meisten benutze Wrapper wie MFC, wxWidgets, VCL und VCF. (es gibt noch viel mehr auf dem Markt)
also ich fuehl mich keineswegs angepisst, ich mag die winapi weil ich es mag die volle kontrolle zu haben und auch zu wissen was welche funktion macht usw, aber wenns um die arbeit und zeit geht, hab ich auch keine probleme damit eine andere lib zu verwenden
Artchi schrieb:
Klar, aus Spaß mache ich auch Dinge, die ich beruflich nicht machen würde. Auch viele Leute, die Programmierung zum Hobby haben, kapseln nicht erst die Win32-API. Sondern wollen z.B. einfach ein Produkt (was weiß ich, z.B. Vereinsveraltungs-Programm) programmieren. Und sich nicht mit Win32-API rumkrepeln. Nein, da wird wxWidgets genommen und ab gehts mit der eigentlichen Arbeit (dem eigentlich Ziel).
aber sieh das so - sobald ich meine kapselung hab {die ich ja spaeter immer weiter erweitern werd} brauch ich mich fuer meine zusaetzlichen eigenen programme auch nicht mehr drumm kuemmern - ist wie als wenn ich ne andere lib verwende, der vorteil dabei ist sogar das ich mich nicht einlernen muss sondern weiss welche funktion was moechte, was macht und was zurueck gibt usw
Artchi schrieb:
Also, man sollte nicht so tun, als ob für jeden die Win32-API sinnvoll ist und nicht gleich beleidigt sein.

man sollte immer benutzen was dem ziel angemessen ist - sei es lib, oder sprache oder gar das mittagessen #gg
ich bin da keine sprache voreingenommen, sind mal denk ich die meisten hier nicht
-
Wenn ich das doch jetzt richtig verstehe, dann ist die WinAPI doch die Fenster,Netzwerk,Sound-Film Schnittstelle zu Windows? Einfach #include <windows.h> und los gehts? Wie funktionieren dann aber QT etc...? Kapselt QT unter Windows die WinAPI und macht es so einfacher? Weil der Sinn von solchen Libs wie QT ist ja wohl die Programmierung zu vereinfachen?
Mh aber wie hat alles ihren Ursprung gemacht? Ich mein die WinAPI ist doch auch einfach nur eine header Datei?
Die muss ja auch mal jemand Programmiert haben? Aber wie hat derjenige das gemacht? Weil es ist doch in reinem C\C++ nicht möglich bunte Bildchen,Ordner,Sound etc... (okay man bekommt son Piepston ausm PC wenn man will :D) zu programmieren? Wie funktioniert das? Und wenn es unter Windows eine WinAPI gibt gibt es dan unter Linux soetwas auch?
Fragen über Fragen ich hoffe ihr könnt sie mir beantworten und mir die Geschichte mal bisschen erklären!
Dankeschön schon mal im Voraus.
-
Lies ein Buch über Betriebssysteme, z.B. von Tanenbaum. Wie soll man dir jetzt den Ursprung erklären? Oder besorg dir einen C64 und programmier darauf in Assembler, dann weißt du wie man in C++ und C Grafik und Fenster ganz zum Schluss doch machen kann.
-
@Artchi: Glaub der wichtigste Vorteil bezüglich WinAPI ist eigentlich (und der wurde glaube ich noch nicht oder nur implizit erwähnt): Sie ist verdammt schnell.
Mal noch ne kleine Frage (an Dich
):
Du kennst Dich ja anscheinend sehr mit Frameworks aus...
:
Ähm welches Framework würdest Du mir empfehlen, dass einerseits möglichst guten C++ Support hat (Exceptions, Vererbung), anderseits kostenlos ist, möglichst plattform-übergreifend arbeitet (Windows, Linux, Mac ... reicht ja eigentlich) und, das wichtigste: Auch eigene Styles zu lässt.Haste da vllt n Tipp/Empfehlung ? Ich danke schonmal
.PS: Hab mir Deine Seite auch schonmal angeguckt - echt gelungen
.
-
Glaub der wichtigste Vorteil bezüglich WinAPI ist eigentlich (und der wurde glaube ich noch nicht oder nur implizit erwähnt): Sie ist verdammt schnell.
Hem, das widerspricht aber nicht einer Kapselung. Soll heißen, wenn ich die Win32-API kapsel, wird trotzdem die Win32-API genutzt. Wieso sollte hier ein Performancenachteil entstehen? Eine Kapselung versteckt nur den Aufruf, es ersetzt nicht die API. Wenn ich ein Fenster in Java erstelle, wird am Ende auch nur ein Win32-Fenster erzeugt, Java kapselt das ganze nur. Gut, ob Java der Flaschenhals ist, ist eine andere Geschichte.
Aber das Fenster selbst, ist das gleiche wie in einem C-Programm. In C++ hast du durch Inlining im optimalen Fall 0% Performance-Verlust. Lass es einen Taktzyklus mehr für die vtable sein. Naja, weiß nicht wo da eine direkte Win32-API-Nutzung schneller sein soll.Ähm welches Framework würdest Du mit empfehlen, dass einerseits möglichst guten C++ Support hat (Exceptions, Vererbung), anderseits kostenlos ist, möglichst plattform-übergreifend arbeitet (Windows, Linux, Mac ... reicht ja eigentlich) und, das wichtigste: Auch eigene Styles zu lässt.
Haste da vllt n Tipp/Empfehlung ? Ich danke schonmal
Oh, das ist leider sehr schwer. Leider suche ich selbst noch nach so einem Framework.
Selbst die Java-Welt hat mittlerweile mehrere GUI-Libs, obwohl es dort eine Standard-Lib namens Swing gibt. Z.B. setzen immer mehr Java-Eclipse-Projekte auf SWT. Weil SWT andere Vorteile ggü. Swing hat. Aber viele benutzen Swing, weil SWT ein paar andere Nachteile hat.Ich kann dir sagen, welche Libs ich nicht empfehlen würde, weil nicht in deine Forderungen passen: wxWidgets, Ultimate++ (keine Buildfiles im Lieferumfang!), VCL, MFC, WTL, VACA, FLTK und vielleicht noch FOX. Bleibt nicht mehr viel übrig: gtkmm und VCF. Wobei nur gtkmm von beiden eigene lokale Themes erlaubt. VCF aber wiederrum globale Themes nutzt. Schau in meine Übersicht, was von beiden für dich besser ist. Aber gtkmm ist am Ende halt doch verbreiteter.
Deshalb habe ich die Übersicht auch geschrieben: es kann einem schon mal einen Knoten im Gehirn bringen. "Ein verwirrendes Wirrwar!" (von Dan Akkroid aus dem Film Evolution) :p
-
Artchi schrieb:
Ich kann dir sagen, welche Libs ich nicht empfehlen würde, weil nicht in deine Forderungen passen: wxWidgets, Ultimate++ (keine Buildfiles im Lieferumfang!), VCL, MFC, WTL, VACA, FLTK und vielleicht noch FOX.
Könntest du das vielleicht im einzelnen näher begründen? MFC ist klar, aber der Rest würde mich näher interessieren...
-
Wenn man sich die Anforderungen von FreakCoder anschaut, und dann meine Bemerkungen auf meiner GUI-Übersicht, wird einem klar, warum soviele Kandidaten ausscheiden. Alle reinen Win-GUI-Libs fliegen schon mal raus, weil Multiplatform gefordert war. Bleiben noch viele übrig, aber erfüllen selten die eigentlich selbstverständlichen C++-Features wie Namespaces, Exceptions, RTTI, Enums, Konstanten usw.
wxWidgets und FOX arbeiten noch unnötigerweise mit Makros, an viel genutzten Stellen. Werden einfach nicht modernisiert, zumindest nicht kurzfristig. U++ ist dummerweise nur mit TheIDE nutzbar, obwohl es eigentlich gut ist.
FLTK 2 wird zwar modernisiert, hat aber eine sehr nüchternes und unaktuelles Widget-Design (Win98-Style!) und man kann es auch nicht wirklich ändern. Wer unbedingt Win32-Controls haben will, hat eh nur wxWidgets und VCF zur Auswahl, wobei VCF die viel modernere C++-Lib von beiden ist. gtkmm ist auch modern, zeichnet seine Widgets aber selbst, aber man kann wenigstens das Design der Widgets umschalten.Kann man aber alles auf meiner Übersicht nachlesen.
Wenn auch nicht immer ganz so spektakulär wie in diesem Posting. 
-
Deine Übersicht ist sehr gut, danke für den Link

Artchi schrieb:
wxWidgets und FOX arbeiten noch unnötigerweise mit Makros, an viel genutzten Stellen. Werden einfach nicht modernisiert, zumindest nicht kurzfristig. U++ ist dummerweise nur mit TheIDE nutzbar, obwohl es eigentlich gut ist.
FLTK 2 wird zwar modernisiert, hat aber eine sehr nüchternes und unaktuelles Widget-Design (Win98-Style!) und man kann es auch nicht wirklich ändern. Wer unbedingt Win32-Controls haben will, hat eh nur wxWidgets und VCF zur Auswahl, wobei VCF die viel modernere C++-Lib von beiden ist. gtkmm ist auch modern, zeichnet seine Widgets aber selbst, aber man kann wenigstens das Design der Widgets umschalten.Danke für deine Ausführungen

(
Wenn du erlaubst, noch ein paar Ergänzungen zu deiner Übersicht aus Sicht eines VCL-Benutzers:
- der Quelltext der VCL ist verfügbar und bei Turbo C++ dabei
- zumindest in bezug auf deine Definition ("Makrohölle") ist die VCL durchaus gutes C++-Design. Und auch ansonsten würde ich sie als gutes objektorientiertes Design bezeichnen - eben in Pascal. Namespaces, Exceptions, RTTI, Enums etc. werden natürlich verwendet
- es gibt eine VCL für Win32 und für .NET (Versionen für .NET CF und WPF sind in Arbeit)
)Bzgl. FLTK: Nichts gegen Win98-Style!

Deine Beschreibungen zur VCF klingen gut. Die werde ich mir mal ansehen...
-
Artchi schrieb:
Glaub der wichtigste Vorteil bezüglich WinAPI ist eigentlich (und der wurde glaube ich noch nicht oder nur implizit erwähnt): Sie ist verdammt schnell.
Hem, das widerspricht aber nicht einer Kapselung. Soll heißen, wenn ich die Win32-API kapsel, wird trotzdem die Win32-API genutzt. Wieso sollte hier ein Performancenachteil entstehen? Eine Kapselung versteckt nur den Aufruf, es ersetzt nicht die API.[...]
Ähm naja wenn man die MFC einbindet, bindet man meistens auch Dinge ein, die man nie benötigt. Dadurch wird das Programm unnötig 'klobig'
.Ansonsten, erstmal danke für die Ausführungen! Sieht ja stark danach aus, als würde ich mir das gtkmm-Framework genauer ansehen
.
-
der Quelltext der VCL ist verfügbar und bei Turbo C++ dabei
Ja, aber ist doch kein Opensource, oder? Von der MFC ist der Source auch einsehbar. Aber ich darf ihn nicht verändern und weiter geben. Ich darf ihn nur einsehen. Wenn dagegen die VCL-Lizenz erlaubt, den Source frei zu verändern und weiter zu geben, wäre es Opensource und ich ändere es entsprechend um. Wenn nicht, bitte einen besseren Begriff nennen. Wird schwierig.

- zumindest in bezug auf deine Definition ("Makrohölle") ist die VCL durchaus gutes C++-Design. Und auch ansonsten würde ich sie als gutes objektorientiertes Design bezeichnen - eben in Pascal. Namespaces, Exceptions, RTTI, Enums etc. werden natürlich verwendet
Ich habe spezielle Compiler-Befehle gesehen. Läuft die VCL auch unter MSVC und Mingw? Weiterhin war mir in Erinnerung (kann auch anders sein), das Attribute public sind?
-
CodeFinder schrieb:
Ähm naja wenn man die MFC einbindet, bindet man meistens auch Dinge ein, die man nie benötigt. Dadurch wird das Programm unnötig 'klobig'
.das ist bei c++ oft so.
einmal std::string benutzt oder 'cout' und schon wird die .exe fetter...
-
ten schrieb:
CodeFinder schrieb:
Ähm naja wenn man die MFC einbindet, bindet man meistens auch Dinge ein, die man nie benötigt. Dadurch wird das Programm unnötig 'klobig'
.das ist bei c++ oft so.
einmal std::string benutzt oder 'cout' und schon wird die .exe fetter...Das hat aber was mit Template-Instantiierung zu tun... . Das gibts ja bei der MFC (leider ?!
) nicht...