Bücher für WinAPI
-
C. Wenn du C++ willst, nimm eines der zahlreichen Frameworks, aber für den Einstieg ins Windows-API mußt du dich mit C abfinden, da sie nur ein C-Interface bereitstellt.
-
unter frameworks versteht man dann VCL und MFC, richtig?
Was sind denn die Unterschiede zwischen WinAPI und VCL&MFC, außer dass man unter WinAPI kein C++ verwendet?
-
MFC "wrappt" die WinAPI, das heißt, es baut anhand der bereitgestellten C-API Klassen auf. Wobei die MFC nicht mehr das feinste C++ ist.
-
und was ist mit VCL?
-
-
also, das heißt, MFC und VCL bauen beide auf WinAPI auf, mit VCL ist das Erstellen
von Windows-Programmen etwas vereinfacht, und die MFC ist die tollste, weil am meisten benutzt und komplexer als VLC, hab ich das richtig verstanden?
-
Wenn Du unter *Windows* arbeitest und Fenster erzeugst, baut *alles* auf die WinAPI auf; egal ob MFC, VCL, WinForms, Avalon ,wxWidgets oder was es sonst noch gibt...
-
MFC und VCL sind beide WinAPI-Wrapper. Die MFC sind bereits recht alt und nach den Kriterien objektorientierter Programmierung relativ miserables C++, von einem Neueinstieg in die MFC ist nicht nur deshalb abzuraten.
Die VCL ist in Object Pascal geschrieben; in bezug auf die Objektorientierung ist sie recht gut (beim .NET-Framework hat auch Microsoft einiges von der VCL abgeschaut), nur verwendet sie eben einige Sprachfeatures von Object Pascal (Properties, Closures, MetaClasses etc.), die in Standard-C++ nicht existieren. Um die VCL trotzdem in C++ verwenden zu können, hat Borland den hauseigenen C++-Compiler mit einigen Erweiterungen ausgestattet (zwar in wesentlich geringerem Umfang, aber entfernt vergleichbar mit dem, was Microsoft mit C++/CLI macht). Die VCL kannst du also nur mit dem Borland-Compiler benutzen.
Wenn dich die Entwicklung mit der VCL interessiert, schau dir mal Turbo C++ oder Turbo Delphi an. Aus eigener Erfahrung kann ich sie sehr empfehlen - unter den mir bekannten Frameworks eines der produktivsten.
Allerdings sei auch der Nachteil genannt: wie erwähnt, ist die VCL nicht C++-standardkonform, sondern verläßt sich auf einige compilerspezifische Erweiterungen, du mußt also den Borland-Compiler benutzen. Auch implementiert der C++-Compiler von Borland ein paar Sachen im C++-Standard nicht ganz so gut wie der MSVC-Compiler oder der GCC, weshalb es z.B. ein paar Probleme mit Boost geben kann. Wenn du aber nicht ganz fortgeschrittene, abgedrehte Template-Konstrukte baust, wird dich das nicht stören.
Und CodeGear arbeitet (endlich!) daran...Eine weitere Alternative wäre .NET 2.0 oder 3.0 mit WinForms oder WPF, dann bist du allerdings vom Microsoft-Compiler (zurzeit der einzige, der C++/CLI implementiert) und vom .NET-Framework abhängig. WPF-Anwendungen laufen zudem erst ab Windows XP SP2.
Willst du plattform- oder compilerunabhängig sein, so mußt du auf ein anderes Framework zurückgreifen. Unter http://www.kharchi.de/cpp_gui/index.html findest du eine gute Übersicht zu diesem Thema.
-
Auch wenn nicht perfekt, aber in Zusammenhang mit .NET darf wohl Mono genannt werden, das .NET Anwendungen auch unter Linux laufen lässt (was ich ausprobiert habe, lief gut).
-
Wenn Du unter *Windows* arbeitest und Fenster erzeugst, baut *alles* auf die WinAPI auf; egal ob MFC, VCL, WinForms, Avalon ,wxWidgets oder was es sonst noch gibt...
...wie geht es dann, dass WxWidgets plattformunabhängig sind, wenn sie auf die WinAPI zugreifen ? Und wie sieht's mit allen anderen Bibliotheken aus ?
-
mikey schrieb:
...wie geht es dann, dass WxWidgets plattformunabhängig sind, wenn sie auf die WinAPI zugreifen ?
#ifdef WIN32 ... #endif #ifdef _MAC ... #endif ...Kein GUI-Framework ist wirklich plattformunabhängig. Manche unterstützen nur eben mehrere Plattformen.
-
Achso das hatte ich mir gedacht, dass die mit Präprozessor Direktiven arbeiten ...