VS.NET 2003: Unabhängigen MS-C++-Code generieren!
-
Für die Windowsprogrammierung möchte ich kein ANSI-C++ oder nur WinAPI nutzen, denn der Aufwand steht in keinem Verhältnis zur Rentabilität. So nutze ich Borland-Buggy-Builder (BCB 6.0) und VCL. Was recht angenehm ist, wenn denn der Builder nicht schlechter als VS.NET wäre. Der Vorteil an der VCL ist, dass ich diese komplett in eine .exe-Datei einbinden kann.
Bekomme ich so etwas auch in der .NET-Version hin? Benötigt MFC nicht Runtimes? Was ist diese Managed-Code und braucht dieser die .NET-Umgebung?
Ziel: Durch zuhilfenahme von sinnvollen und umfrangreichen Bibliotheken unabhängige Windows-Anwendungen in C++ erstellen.
R.
-
Du kannst auch die MFC statisch linken.
.NET kann man nicht statisch linken, es ist ja eine Virtual Machine - die muss separat installiert werden.
-
O, danke. Das klingt interessant. Wie sieht es mit der Geschwindigkeit und MFC aus? Ist es sinnvoll und schnell? Teile mir sonst einfach Deine subjektive Meinung mit, schließlich wirst Du etwas Erfahrung in der C++-Programmierung haben.
R.
-
Dieser Thread wurde von Moderator/in CMatt aus dem Forum C# und .NET in das Forum MFC mit dem Visual C++ verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?Dieses Posting wurde automatisch erzeugt.
-
rafa schrieb:
O, danke. Das klingt interessant. Wie sieht es mit der Geschwindigkeit und MFC aus? Ist es sinnvoll und schnell? Teile mir sonst einfach Deine subjektive Meinung mit, schließlich wirst Du etwas Erfahrung in der C++-Programmierung haben.
R.Hängt einzig un allein von deinen Vorlieben ab. Manche Leute mögen das Design von MFC nicht, andere das von VCL nicht. Die MFC orintiert in sachen Namesgebung und Aufbau sich sehr stark an der WinAPI, weshalb sie einige Leute nicht mögen (die, die sich mit der WinAPI nicht anfreunden können) und andere leiben (die, die sich vorher mit WinAPI beschäfitgt haben).
Von der Geschwindigkeit wird es keine Größen unterschiede geben.. ob da jetzt ist 50 Zeilen code mehr oder weniger drinnen sind ist für ne GUI irrelevant.
-
Du wirst, wie schon gesagt, keine Geschwindigkeitsunterschiede zwischen reiner WinApi und MFC bemerken, da MFC die WinApi kapselt und somit ihre Funktionen (in Klassen gekapselt) verwendet.
-
Shade Of Mine schrieb:
.NET kann man nicht statisch linken, es ist ja eine Virtual Machine...
Genaugenommen ist es ein JIT-Compiler, denn die Dinge werden ja nicht
interpretiert wie bei Java. Ich hab da im C++-Linker eine Option gefunden,
sie heisst "/NOASSEMBLY".
Habe es zwar noch nicht ausprobiert, aber da es NoAssembly
heisst, denke ich mal, dass keine Assembly erstellt wird, weshalb auch
kein .Net gebraucht werden sollte. Ihr könnt es mal ausprobieren...
-
BlueShift schrieb:
Shade Of Mine schrieb:
.NET kann man nicht statisch linken, es ist ja eine Virtual Machine...
Genaugenommen ist es ein JIT-Compiler, denn die Dinge werden ja nicht
interpretiert wie bei Java.Ah, .NET ist ein Jitter? Interessant... Und woher kommen dann die ganzen Funktionen, Klassen, etc.?
Und Java wird nicht gejittet?
Finde ich noch interessanter...Kann es sein, dass du nicht weisst wovon du sprichst?
-
Ich dachte immer, dass Java nur interpretiert und nicht kompiliert wird.
Unter einer VM versteht man doch eine virtuelle Maschine, die irgendwelchen
Code interpretiert. Oder hatte ich da was falsch verstanden ?mfg BlueShift
PS: Ich hab nie mit Java gearbeitet...
-
BlueShift schrieb:
Ich dachte immer, dass Java nur interpretiert und nicht kompiliert wird.
Java wird (meistens) gejittet, wie .NET
Aber es gibt auch Java Compiler - auch wenn es nur wenig Sinn macht, Java zu kompilieren.Unter einer VM versteht man doch eine virtuelle Maschine, die irgendwelchen
Code interpretiert. Oder hatte ich da was falsch verstanden ?Interpretieren und Jitten sind 2 verschiedene Sachen, auch wenn sie einander aehndeln.
Die Java Virtual Machine (oder auch Java Runtime Environment - ka wie man das richtig nennt) und das .NET Framework sind sich _sehr_ aehnlich - der technische Unterschied ist im Prinzip nur, dass .NET Sprachenneutral ist.