Unterschiede zu MFC
-
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...
-
CodeFinder schrieb:
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...doch. mfc hat auch ein paar templates mit dabei.
-
ten schrieb:
doch. mfc hat auch ein paar templates mit dabei.
Echt ? Welche (z.B.) ?
-
CodeFinder schrieb:
ten schrieb:
doch. mfc hat auch ein paar templates mit dabei.
Echt ? Welche (z.B.) ?
einige von den collections, CArray, CList usw...
-
Ja, z.B. CString.
Allerdings ist CString nicht mehr in der MFC sondern ATL drin.
-
Hm na ok, ich benutze weder das eine, noch das andere
(und wahrscheinlich bald gtkmm ).
-
CodeFinder schrieb:
(und wahrscheinlich bald gtkmm)
dann sehen deine programme bald so hässlich aus wie 'the gimp'