Einsteigerfrage zu MFC
-
Walnut_Burl schrieb:
Ist ein Projekt aber mit VS kompiliert gebraucht es automatisch das .NET Framework. Ich hatte schon einmal einem Freund eine Datei (MFC) geschickt und er konnte die Datei nicht öffnen obwohl er die Redistributale hatte. Nach Installation des Frameworks lief alles glatt.
Dann lag es an sonst etwas.
Das .NET Framework ist für MFC Projekte nicht notwendig und muss auf dem Zielsystem NICHT installiert sein.
-
Es wird doch gebraucht:
http://en.wikipedia.org/wiki/Microsoft_Foundation_Class_LibraryVisual C++ 2010 --- MFC 10.x (mfc100.dll), .NET 4.0 --- Est. 2010
MFC benutzt nämlich schon seit langer Zeit Funktionen des .NET Frameworks.
-
Walnut_Burl schrieb:
Es wird doch gebraucht:
http://en.wikipedia.org/wiki/Microsoft_Foundation_Class_LibraryVisual C++ 2010 --- MFC 10.x (mfc100.dll), .NET 4.0 --- Est. 2010
MFC benutzt nämlich schon seit langer Zeit Funktionen des .NET Frameworks.
Nicht alles was in Wikipedia steht stimmt. Oder muss so verstanden werden, wie Du es interpretierst!
Das .NET 4.0 Framework kann benutzt werden, wenn Du gemischte Anwendungen baust.Ansonsten zeig mir ein MFC-Projekt in der .NET wirklich benötigt wird.
Zeigt mir eine EXE und schau bitte vorher mal mit DEPENDS rein.
Definitiv kann ich Dir versichern: Das .NET Framework ist für MFC Software nicht notwendig.Willst Du einen Beweis?
Hier ein kleines Programm, dass mit der MFC, den neuen MFCNext Klassen und VC10 erzeugt wurde.
http://blog.m-ri.de/index.php/2010/06/01/tool-screen-ocr-version-2-0-einfach-mal-texte-vom-monitor-aus-bildschirmausschnitten-und-grafiken-in-die-zwischenablage-kopieren/BTW: Ich weiß wirklich von was ich rede...
BTW 2: Diese unwahren Behauptungen, dass die MFC das .NET Framework benutzen haben der weiteren Verbreitung und der Nutzung von VC seit der 200xer Versionen extrem geschadet!
BTW 3: Ich warte gerne auf einen gegenteiligen Beweis. Bitte Upload-Link des Sourcecodes (Projektes) und der Binaries angeben...
-
Ich gebe mich geschlagen
. Du hast gewonnen!Ich werde natürlich weiterhin nach einem Beweis suchen
-
Hi Walnut,
Beweis suchen ?
Es ist eine ganz einfache Dynamic die dem zugrunde liegt, was zuerst da war
ist automatisch und unabdingbar von seiner Natur her so beschaffen, das es
von späteren Generationen nicht abhängig sein kann!Wie sollte das historisch funktionieren ?
Also die Kette der Abhängigkeit beginnt mit dem binären Funktionscode der Cpu,
diese Menomic's werden durch eine Maschinensprache als Assembler präsentiert.
Der Nächste der dann kommt ist die Implementation von C , nun werden damit
Objekte abgebildet die einer Hardwareabstarktion gleichkommen, man nennt diese
Schichten HAL.
(hat mit Treibern nix zu tun, sondern mit dessen nicht vorhanden sein!)Auf der HAL(HardwareAbstraktionsLayer) wird mit viel Aufwand die API des
Systems aufgesetzt, das dann eine Schnittstelle zu der Hardware ist,
die das system im TreiberSet "gefunden" hat oder ebend nicht fand.Jetzt werden solche API Interfaces in DLL's verpackt Kern32.dll Ole32 dll
dann erst, wurde die MFC erschaffen, diese verkapselt elementareGrundfunktionen der unhandlichen API, zu einem nett ansprechbaren hirarisch
logischen Gesamtzugang um die untersten Funktionen der Hardware erreichen
zu können.Alles was danach kommt nutzt die API seltend direkt, das war bis win95 nicht
so,jeder sprach dort erstmal die unterste API an, ich denke nicht das jemand
gut daran tut, eine Windowssoftware zu entwickeln ohne je ein Programm auf
dieser Ebene erstellt zu haben !!Die MFC verkapselt die API
Das "NetGesülz" und auch Runtimelibs die niemand extra benötigt
(man linkt statisch also braucht man keine runtime extra liefern)
sind schnick schnack Schichten. Niemand benötigt eine Arbeitsabnahme
durch einen "Manager" wozu dann noch selber was machen ???Es sei denn , das man Oberflächen herstellen möchte (API's in der API),
doch diese sind immer undankbar, niemand will das wirklich !
Und nur dafür ist NetFrame/#f /#c / Flasplayer und pascal / basic nützlich.Und glaub mir nichts ist abhängiger von MFC
-
Die Win-API ist doch die Windows Schnittstelle und MFC eine Bibliothek die diese Schnittstelle nutzt?
Also im Moment beschäftige ich mich eg mehr noch mit reinem C++ um das erst mal besser zu können, habe jedoch auch schon bisschen mit Qt herumgespielt.
Aber wenn ich dann mal richtig anfange mit GUI's und so würd ich gern bei einer Bibliothek bleiben, da es mir auch reichen würde nur für Windows zu programmiere, könnte ich mir auch gut vorstellen die MFC zu nehmen.
Jetzt wollt ich mal fragen was ihr davon haltet ob MFC empfehlenswert ist und vor allem welche IDE soll ich nutzen?
Geht das auch mit Code-Blocks oder muss ich dann Visual Studio nehmen( ist doch nicht kostenlos oder? ) ?
Und gibts für MFC auch so ein Tool wie den Qt-Designer um sich die Oberfläche zusammen zu klicken?
Und was empfiehlt sich um MFC zu erlernen? Bücher oder Online Tutorials?Schonmal vielen Dank im voraus=)
Gruß freeG
-
Wenn Du die MFC nutzen willst empfiehlt sich eindeutig Visual Studio 2010. (Nicht Express!).
1. Gibt hier wieder einen guten Classwizard.
2. Erweiterungen der MFC die seit VC-2008 SP1 auch verfügbar sind.
-
Ok, aber Visual Studio 2010( nicht express ) kostet doch oder etwa nicht?
Kannst du die MFC empfehlen?Dann noch ne Frage, was ist eigentlich Visual C++ und was ist das C++/Cli und was genau ist .NET, aus dem Wiki werd ich net so schlau, und C#?
Danke schonmal
Gruß freeG
-
Martin Richter schrieb:
Wenn Du die MFC nutzen willst empfiehlt sich eindeutig Visual Studio 2010. (Nicht Express!).
In den Expressversionen ist die MFC nicht dabei, d.h. du musst schon zu den Vollversionen greifen oder tricksen viá SDKs mit impliziter MFC.
-
Ja gibt es denn so was um die Oberfläche zusammen zu klicken?
Könnt ihr mir denn MFC empfehlen, oder eher nur abraten?
Oder sollte man eher direkt die Win-API verwenden?
Und vor allem, was ist denn nun dieses Visual C++ und was ist C++/ClI und C# und das .Net?Hoffe könnt mir noch ein bisschen helfen
Danke gruß freeG
-
fr33g schrieb:
Könnt ihr mir denn MFC empfehlen, oder eher nur abraten?
Nur abraten. Die MFC ist wohl mehr etwas für den professionellen Einsatz, für Hobbyprojekte nimm besser Qt oder wxWidgets. Da kommt man einerseits schneller rein und andererseits laufen die dann auch unter Mac/Linux. (Davon mal abgesehen: ohne VS Professional wirds eh nix.)
-
Ok und kann mir trotzdem jemand die oben genannten Begriffe kurz ma erläutern?
Danke gruß freeG
-
Visual C++ ist integrierter Teil von Visual-Studio, also keine eigene Sprache, sondern die Oberfläche zur Entwicklung von C++-Programmen.
C++/CLI und .Net sind eigentlich dasselbe. Hier handelt es sich um sogenannten "managed Code". Dabei werden sogenannte Assemblies als Teil des Codes verwendet, die zur Laufzeit vom Interpreter übersetzt werden. Der C++/CLI beinhaltet eine eigene Speicherverwaltung auf dem Heap, die nicht mehr benötigte Objekte automatisch zerstört (Garbage Collection).
C# ist eine von Microsoft entwickelte Sprache, die speziell auf die Verwendung von Windows Forms ausgerichtet ist und eine eigene Syntax hat. Auch C# hat eine intelligente Speicherverwaltung, sodass man sich um das Aufräumen des Heap nicht kümmern muß
Mfg
Wilfried
-
Ok, danke schön für die Antwort=)
Jetzt versteh ich das.Und könnt mir nun MFC empfehlen oder eher abraten?
Danke schonmal
Gruß freeG
-
Ich kann dir MFC nur empfehlen. Wenn du dich eingearbeitet hast, wirst du sie nicht mehr missen wollen.
Mfg
Wilfried
-
Ok erst mal Danke für die Antwort=)
Welche Lizenz hast du denn genommen?
Ja ich finde einfach Qt, gefällt mir nicht so ganz, weiß auch net warum, find auch blöd dass es für alles eigene Klassen gibt, auch wenns in der STL vorhanden ist, sprich Vector, String und so weiter.
Über weitere Empfehlungen würd ich mich natürlich freuen.
Gruß freeG
-
Ich hatte in der Vergangenheit immer die Standard-Version, jetzt die Professional, da es Standard nicht mehr gibt.
Mfg
Wilfried
-
Und könnt mir nun MFC empfehlen oder eher abraten?
So ne allgemeine Einschaetzung wird keiner richtig abgeben können.
Als "ernsthafter" C++ programmierer sollte man recht schnell mit jeglicher GUI Bibliothek klarkommen.
MFC hat auch Ihre Vorteile, aber IMHO gehoert die Einsteigerfreundlichkeit ned dazu. Das natuerlich auch Geschmackssache, aber ich empfinde QT und wxWidgets beispielsweisse als intuitiver. Das wuerd ich Einsteigern eher empfehlen.
MFC waehlen wir, z.b. wenn das geruesst recht duenn um die winapi sein muss. Man also viele WinAPI Aufrufe expliziet tun muss.
Wenn man modular Windows-Ressourcen okupieren und benutzen muss ... beispielsweisse sowas wie controls baust, die sich in nem von einer Hostapplikation verwalteten HWnd zeichnen muessen ...
etc.Zu den libs / dlls
man kann auch die c++ runtime statisch linken (unabhaengig dann von der redistributable)
man kann auch andere GUI libs statisch linken.
Das einzige was man ned statisch linken kann, iss die WINAPI selber ^^ also ne kernel.dll, gui.dll etc muss deine App meistens noch finden.
Also ich hab scho Apps unter qt geschrieben, die liefen anstandslos unter allem, was ansatzweisse nach windows roch, (also kernel.dll, gui.dll ... ) und "Portable Executable" dateien ausfuehren kann, Intel Architektur mal vorrausgesetzt.
Fuer andere Plattformen haett mans neu uebersetzen muessen.
Allerding iss dann nen simples grafisches "Hallo World" auch mal 20-30 Mb gross ^^Wenn dich bissi mit kompilieren / linken auskennst, kannst die abhaengigkeiten schon auf wenige dlls der WINAPI schon runnersetzen.
Natuerlich musst dann die verwendetetn 3d party Libs meist selber kompilieren.
Ob das immer der heilige Gral iss, iss ne andere sache.
Wenn man weiss wie, und das zielsystem ned bis zur hoffnungslosigkeit verbogen ist, kann man fast alles aus einem verzeichniss starten (impliziet mit eigener dynamischer version der c++ runtime)
Ciao ...
