MFC -> tod
-
Erhard Henkes schrieb:
Welches würdet ihr einsetzen, um WinAPI und MFC zu umgehen?
FLTK hab ich mir noch nicht wirklich angesehen. Aber wxWindows sah sehr MFC ähnlich aus vom Aufbau. Deswegen würde ich dir zu GTKMM raten, da du dann endlich mal schönes C++ benutzen kannst. (wxWindows lohnt sich aber vermutlich eher als Portierungsziel, für MFC ANwendungen)
SirLant schrieb:
Ich wage mal zu behaupten, dass man sich in 3Jahren doch recht gut in der Winapi
zurechtfinden dürfte und bis dorthin mit dieser doch etwas Spass haben kann, daher
würde es sich meiner Ansicht nach auf alle Fälle lohnen."Spass" kannst du auch mit GUI Toolkits haben
Also wenn die WinAPI im laufe von 3Jahren abgeschafft wird, ist die Zeit das zu lernen eine tote Investition.SirLant schrieb:
Und bei solchen GUI-Toolkits ist man letzten Endes auch auf Leute angewiesen die
diese auf die WinAPI zurecht schneiden.du wirst dich wohl kaum für ein Toolkit entscheiden, was noch nicht auf deine Platform portiert ist
SirLant schrieb:
Wenn man allerdings auch direkt mit einem OS arbeiten kann ist man unabhängiger.
nö, da die WinAPI proprietär ist, ist man vom gutdünken von MS abhängig. Ein GUI-Toolkit wrapped dir einfach die API und du kannst theoretisch noch in 20Jahren dein Programm verwenden (bis die bisherigen GUIs abgelöst werden, von Cyber-Virtuell-Internet-XML-Java-dotNET-Mega-Super-Firewire-USB2-TFT-3D-Reality-GUIs ;))
-
Ist C# wirklich die Zukunft? Braucht man das unbedingt bei .NET? Oder reichen C++ und JAVA aus?
-
CME386 schrieb:
Ist C# wirklich die Zukunft? Braucht man das unbedingt bei .NET? Oder reichen C++ und JAVA aus?
Nein du kannst auch Managed C++ oder Visual Basic .NET oder J# (Java for .NET) verwenden!
.NET ist sprachneutral.
Managed C++ hat den Vorteil, dass du Managed und Unmanaged Code mixen kannst und mit Visual Studio 2003 .NET ist auch ein GUI-Builder dabei.
Ob J# genau die gleichen Sprachelemte hat wie Java von Sun weiss ich nicht, allerdings wird wohl klar sein, dass J# nicht normale Klassenbibliotheke benutzt.
-
@CME386: Das sind zwei Fragen.
Ist C# die Zukunft: Würde ich nicht sagen, außerdem kann man nicht C# mit C++ vergleichen, denn C# braucht (wie Java) ein Framework. C++ nicht. Anders: Wenn SUN 95 % aller Desktopsysteme gehören würde, würde dann JAVA die Zukunft gehören? Nicht unbedingt, weil die Basis ohne Framework laufen muss.
Braucht man C# bei .NET: Da .NET auf C# basiert kommst Du nicht umher. Du kannst natürlich auf VB.NET od. den anderen .NET-Sprachen entwickeln (ich bevorzuge VB.NET und C++). Daher kann man auf dem Pocket PC (Windows CE) sowohl in C# als auch VB.NET entwickeln. 'managed C++' soll auch nett sein, aber nutze ich aus einem einfachen Grunde nicht: Mache mich wieder vom Framework abhängig (nicht mit None-Managed-C++ von .NET was dem 'normalen' VC++6 ohne MFC entspricht / ketzerisch würde ich gar behaupten, dass sich nichts geändert hat).
In .NET kannst Du in einem Projekt mehrere Sprachen nutzen (C#, C++, VB.NET) und das ist der große Vorteil. Von daher würde ich nicht sagen, dass C# (im Zusammenhang mit C++) die Zukunft gehört.
Für mich ist C# wie JAVA, nur eben von Microsoft (abgesehen von J# was näher an JAVA, wie C# näher an C++ sein soll). Und wenn Longhorn zum großen Teil auf C# basiert ist es so, als wenn SUN meint, es müsse ein OS auf der Basis von JAVA entwickeln. Bis auf den Unterschied, dass C# wirklich schneller und ressourcensparender als JAVA ist.
Fazit: C# ist nett, aber es wird nicht C++ ablösen. Ich wüßte nicht wie (siehe oben: Framework). Es wird wahrscheinlich alle MFC/VCL-C++-Kombinate ablösen, also jene, die unbedingt Externes (Framework) brauchen.
-
Kommt mir das nur so vor oder weiß keiner in der Branche was jetzt Sache ist?
-
So würde ich nicht pauschalisieren. Das liegt daran, dass viele nur was 'gehört' haben und entsprechend Verwirrung entsteht. Etwas 'hören' ist nicht etwas 'wissen'.
... Darauf bauen Foren aber letztlich auf.Wenn Du es sicher wissen willst: www.microsoft.com
-
Was genau ist denn jetzt der Unterschied zwischen Managed und Unmanaged Code? Und kann ich auch Managed C++ mit MSVC6 schreiben?
-
Wenn du auf irgendein System entwickelst, machst du dich abhänig!
Wo her kommen deine Funktionen zum Zeichenen eines Fenster?@CME386
Managed Code
ist die Bezeichnung, das die Freigabe von Speicher ein automatisiertes System (Garbage Collector) und nicht dem Entwickler:Klasse * Objekt = new Klasse();
delete Objekt <- nicht mehr nötig bei Managed Code!Ja du kannst Managed C++ unter MSVC6 entwicklen, wenn du die Lust hast, alle Einstellungen per Hand einzubinden. Ich glaube, da gibst was in der MSDN! Muss du mal durchsuchen!
Kommt mir das nur so vor oder weiß keiner in der Branche was jetzt Sache ist?
Das Überlege ich mir auch wenn ich .NET Wahnsinnige im Forum entdecke!
Sagen wir mal so:
Es gibst Ziele die .NET nicht erreichen wird! Und dann lohnt sich auch eine Lösung in C/C++ zu schreiben!
-
Könnte mir jemand ein gutes Tutorial zum Programmieren mit GTKMM und Dev-C++ nennen, denn wxWindows gefällt mir nicht besonders.
-
-
-
Offtopic: Ihr hattet doch mal irgendwann gesagt das GTK (worauf GTKMM ja aufbaut) unter Windows nicht so ausgereift ist oder so.
Oder hab ich mich da vertan?
-
Managed Code
Q. What is managed code and do I have to use it?A. Managed code runs within the context of the .NET run-time environment. It is not compulsory to use managed code, but there are many advantages to doing so. A program written with managed code using Managed Extensions for C++, for example, can operate with the common language runtime to provide services such as memory management, cross-language integration, code access security, and automatic lifetime control of objects.
Wenn man von C++ und 'managed code' spricht meint man eigentlich die .NET-Variante. Das von Zeus gemeinte ist nur ein kleiner Teil. Wenn man von 'Managed C++' spricht meint man VC++7 (.NET).
@Zeus: Da hast Du mich falsch verstanden. Selbstverständlich mache ich mich von einem System abhängig, ebenso, wie wenn ich für MAC oder PC entwickle. Es ist aber was anderes sich von einer Runtime-Umgebung auf einem System abhängig zu machen, wie im Falle von JAVA und .NET. Und eben das meinte ich mit 'abhängig machen'.
Zitat: 'Das Überlege ich mir auch wenn ich .NET Wahnsinnige im Forum entdecke!'
-
Ob Tot oder nicht, wenn man sich nun noch garnicht mit GUIs beschäftigt hat, schadet es nichts MFC oder WinApi oder sonstiges, bald aussterbendes, zu "lernen". Letztendlich steckt hinter den ganzen GUIs ja ein mehr oder weniger gleiches Prinzip. Das sollte man verstehen und man hat keine Probleme innerhalb ein paar Stunden sich in eine andere Library einzuarbeiten.
Sollte nur nicht darin ausarten, sich drei Jahre lang durch die MSDN zu wühlen um alle möglichen Tricks & Kniffe zu kennen.
-
stimme drgreenthumb zu
ich hab schon ewig nicht mehr MFC programmiert - vor allem weil ich meistens Java mache
und ich muss sage man denkt dann doch immer wieder zurueck wie das in MFC geht und was dann dahinter in der WinAPI passiert
schaden kann es nicht
-
DrGreenthumb schrieb:
Ob Tot oder nicht, wenn man sich nun noch garnicht mit GUIs beschäftigt hat, schadet es nichts MFC oder WinApi oder sonstiges, bald aussterbendes, zu "lernen". Letztendlich steckt hinter den ganzen GUIs ja ein mehr oder weniger gleiches Prinzip.
Volle Zustimmung bis auf 1 Punkt: Die MFC würde ich nicht gerade als gutes Beispiel heranziehen (o; Aber ansonsten hast du recht: Es kochen alle mit Wasser. Ob nun Windows-Explorer oder ein X-Basierender Window-Manager wie CDE, KDE, Gnome etc. ist egal.
-junix
-
junix schrieb:
Die MFC würde ich nicht gerade als gutes Beispiel heranziehen (o;
Jo, stimmt. Man sollte auf jeden Fall schon soweit sein, dass man den Mist rausfiltern kann. Sonst schadet es am Ende doch noch
Wobei ich mich nie so mit der mfc beschäftigt habe, weiß gar nicht wie schlimm die wirklich ist.
-
Wie sieht das denn nun aus, ich hab Erfahrung mit dem Borland Builder welcher eigentlich immer recht gut war um grafische oberflächen zu erstellen. im moment arbeite ich gerade mit mfc, alles mit c++.
Wie sehr unterscheidet sich jetzt .net bzw c# von c++?
Würde ich mich bei einem umstieg sofort zurechtfinden oder darf ich alles wieder von vorne lernen?