MFC -> tod
-
Was genau ist denn .Net?Ist das sowas wie die WinApi?
Ich kann C++ und WinApi.Würde es was bringe,wenn ich auf C# und .Net umsteigen würde?
-
gomberl schrieb:
klassisches GC mit reinem referenz zaehlen gibt es ja fast nicht mehr
Python, Perl, shared_ptr<T> ...
Ich würd Referenzzählung nicht unbedingt klassisch nennen, es ist ja schon nicht ganz klar, ob man das überhaupt zu den Garbage Collectoren dazurechnen kann oder nicht. Der klassische GC-Algorithmus ist wohl eher Mark&Sweep.
Ich bin mir auch nicht ganz sicher, ob Java und .NET in Sachen GC nicht gewaltig ins Klo gegriffen haben, indem sie Finalizer eingeführt haben. Normalerweise muss ein GC nur alle lebenden Objekte finden, und den Rest des Speichers als frei markieren. Gibt es Finalizer, muss er aber auch die toten Objekte abklappern. Da geht eine Menge Potential verloren.
realisticer: Wegen der Bücher, es kann aber auch sein, dass in der Anfangsphase von C# haufenweise kleine miese Drecksbücher wie Pilze aus dem Boden geschossen sind, die jetzt keiner mehr haben will. Ist immer so, wenn es was tolles neues gibt (wobei ich mich einer Bewertung von C# enthalten will
)
-
CME386 schrieb:
AndreasW schrieb:
meiner Meinung nach werden JAVA und .NET nur zur Waffe der Anfänger.
Und was benutzen die anderen?
ich sag ja nicht, das man JAVA oder .NET nicht verwenden sollte. Du wirst es kaum glauben, aber ich schreibe zur Zeit auch JAVA-Programme.
klingt sehr nach: das haben wir frueher nicht so gemacht, warum sollten wir es heute machen
mag sein dass es sich so anhört. Wenn es wirklich eine neue Sprache geben sollte, die was taugt würde ich aber auch sehr gerne wechseln.
Aber weder bei .Net noch bei JAVA sehe ich den Sinn der Entwicklung nicht.OK, es soll eine Plattformunabhängikeit erreicht werden. Oder gibt es offiziell noch einen weitern Grund? Bei JAVA ist das ja auch teilweise gelungen. Aber .Net läuft ja nicht einmal auf Linux. Warum sollte .Net dann eine Berechtigung haben. Weil es mehr Arbeitspeicher braucht ? Weil es langsamer ist? Weil MS Geld damit verdienen will ?
Sicherlich wird sich die Platform auf Plattform-Strategie durchsetzen. Später in ein paar Jahren, wenn die JAVA und .NET- Plattform ebenfalls so versaut sind wie die jetzigen bauen wir halt noch eine Plattform auf der Plattform der Plattform. usw. Macht ja nix, die Rechner werden ja eh jedes Jahr schneller.Es wird das Problem nicht an der Wurzel angegangen sondern nur schön mit Puder dick aufgetragen.
Hirnrissig.
-
AndreasW schrieb:
CME386 schrieb:
AndreasW schrieb:
meiner Meinung nach werden JAVA und .NET nur zur Waffe der Anfänger.
Und was benutzen die anderen?
ich sag ja nicht, das man JAVA oder .NET nicht verwenden sollte. Du wirst es kaum glauben, aber ich schreibe zur Zeit auch JAVA-Programme.
Du hast mich falsch verstanden. Ich wollte deinen Satz nicht anzweifeln, aber meine Lage ist die, dass ich bisher nur auf der Konsole in C++ programmiert hab. Deshalb möcht ich wissen, was sich denn jetzt wirklich lohnt? Was man jetzt lernen sollte, wenn WinAPI und MFC sterben?
-
WinAPI ist noch weit über 3Jahre ein gutes Mittel, weil erst dann Longhorn erscheinen
wird und selbst dann werden noch sehr viele Win2k,WinXP oder sogar noch ältere
Systeme verwenden.
-
SirLant schrieb:
WinAPI ist noch weit über 3Jahre ein gutes Mittel, weil erst dann Longhorn erscheinen
wird und selbst dann werden noch sehr viele Win2k,WinXP oder sogar noch ältere
Systeme verwenden.die win32 plattform wird noch länger bestehen, dank des TCPA
aber das winapi ein gutes mittel ist das bezweifel ich schon jetzt
-
Wenn es die Win32 API nur noch 3 Jahre gäbe, wär das ein sehr guter Grund jetzt nicht mehr damit anzufangen. Bis du gut darin bist isses nämlich so weit.
-
"... Was man jetzt lernen sollte, wenn WinAPI und MFC sterben?"
Diese Frage ist immer noch offen. Ist GTKMM oder WxWindows die Lösung oder C# mit .NET?
Bei Dev-C++ (kostenlos) gibt es bisher folgende Packages als GUI toolkits:
The Gimp Toolkit (GTK+)
wxWindows
Fast Light Toolkit (FLTK)Welches würdet ihr einsetzen, um WinAPI und MFC zu umgehen?
-
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.
Und bei solchen GUI-Toolkits ist man letzten Endes auch auf Leute angewiesen die
diese auf die WinAPI zurecht schneiden.
Wenn man allerdings auch direkt mit einem OS arbeiten kann ist man unabhängiger.
-
So viele Beiträge. Viele habe ich überflogen, aber die meisten tatsächlich gelesen.
Ich programmiere mit .NET. Firmenintern wird .NET in Kombination mit folgenden Sprachen genutzt: C++ (None-Managed-Code), C++ (Managed Code), VB.NET und C#(.NET), sowie ASP.NET (beinhaltet obige Sprachen). MFC kommt nicht zum Zug.
Mir sind viele Unternehmen bekannt, welche früher GUIs in VB6 und Softwareintern mit C++ entwickelt haben und nun auf .NET umgestiegen sind. Sie verdienen recht gut damit.
Zu der eigentlichen Frage: GUIs würde ich nie in C++ machen. Das dauert einfach zu lange. Obwohl ich WinAPI gut finde und aus Spaß GUIs mit WinAPI erstelle (erstellen möchte) ist der Zeitaufwand zu hoch. VB6 und DELPHI sind in dieser Hinsicht angenehmer. Vor allem aus unternehmerischer Sicht. Die GUI-Erstellung macht nur noch aus Designersicht Aufwand.
WinAPI tot: In vielen .NET-Büchern sprechen die Autoren davon, dass mit .NET COM abgelöst werden soll, nicht die WinAPI. Davon habe ich noch nie was gehört. Letztendlich ist die WinAPI die Basis. .NET ist eine eigene Sprache (intern C#, intern-intern ILS), daher können sie nicht sagen, wir schreiben .NET vor, da in dem Augenblick es kaum noch Windowsanwendungen geben würde. Ist zwar vielleicht nett für B. Gates, nur welches Unternehmen lässt sich so zum Umstieg zwingen? Damit könnte sich Microsoft ein großes Eigentor schießen.
Letztendlich versteht der Prozessor (im Allgemeinem) auch nur ASM, von daher werden sie kein ASM verbieten (in diesem Sinne C++, DELPHI, PASCAL...), nur weil sie .NET intensiv nutzen wollen.
.NET Müll: Es ist sehr schön damit zu programmieren. Alles schön gekapselt und vor allem viele sinnvolle Klassen. Mal abgesehen von der klasse IDE die einem viel Arbeit und Stress abnimmt. Aber damit hat MS schon immer getrumpft.
Geschwindigkeit: Ich habe bisher keinen nennenswerten Unterschiede von C++ zu .NET-Sprachen hierin gefunden. Sogar interne Geschwindigkeitstests haben gezeigt, dass in manchen Fällen .NET vorne lag. (Natürlich hängt das sehr stark vom Programm, Programmierer und dem Test ab. Keine Frage.) ... Aber, C++ ist näher an der Hardware!
MFC will ich nicht nutzen. Habe mit 'Windows-Programmierung' von Petzold ein gutes Buch zum Thema. Außerdem empfinde die Struktur von MFC und VCL als nicht sehr schön. Daher lieber WinAPI. Für GUIs ist immer noch .NET da.
LEIDER! Leider ist die .NET-Runtime nahezu 30 MB groß (in Longhorn 80 MB) und die Compact-Edition (Handys, Pocket PC) knapp 3 MB. Also immer noch zu groß. Kommt aber auf die Anwendung und das Anwendungsziel an. Immerhin ist es egal, wenn Du eine Officesoftware schreibst, wenn dann noch 30 MB dazu kommen.
Tipp GUI: Bunte Klick-The-Quick-Software a la Windows XP verkauft sich immer gut. Das ist leider so. Habe XP nur, weil 2000 zu langsam beim Hochfahren und XP mehr ältere Anwendungen unterstützt. Diesen Effekt erlebst Du auch, wenn Du den tollsten KI-Algorithmus mit einer Konsolenausgabe kombinierst und wahlweise mit bunten Grafiken, Männchen.
-
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.
-