MFC -> tod
-
Und .NET hat einen ganz anderen Hintergedanken, in erster Linie geht es um Stabilität und Sicherheit. In vielen Papers legte MS nahe, wer den für Instabilitäten usw. an der Windows Platform schuld hat a) Treiber Programmierer b) Die ganze Hobby/Share ware und auch einige *Szene Software*.
.NET ist kein Stück Sicherere wie MFC. Das Windows instabil ist liegt mehr an die mitgeführten Bugleichen von sogar WIN95. Irgendwann ist ein System was nur wieterentwickelt aber nicht ausgemistet wird instabil. Sicherlich ist die dll- Strategie von Microsoft alles andere als eine gelungen Lösung. Aber eine schlechte Software macht ein Windows-System nicht direkt instabiler.
Selbstverständlich kann Software auf einer Plattform sschaden anrichten. Das kann aber auf jeder Plattform geschehen. Auch .NET und Java.
Wenn Microsoft in sein Sysem aufräumt und eine Longhorn- Version rausbringt, ist diese Version nicht Stabiler durch .Net sondern durch die Ausmistaktion. Eine größere Sicherheit kann Windows doch gar nicht gewährleisten. Zumal sich die COM- Strategie in "Netzwerkkäse" mit vielen Türen als Fehler erweist. Oder würdest du ohne weiteres einfach ein ActiveX- Plugin in deinem Browser runterladen ? Ich weiß jetzt nicht, in wie weit die COM-Techniken sich in .NET und auf dem Langhorn-System weiterverwendet werden, ich glaube aber nicht dass Microsoft von der Strategie abweichen will.
Nun, ersteres wird durch einen neuen satz Api's und Tools entgengewirkt, letzteres per .NET. Denn die ganze Sache mit der Speicherverwaltung und eingriff/überwachung einer höreren *Instanz* biss zur Vereinfachung von z.B. immer wichtiger werdenden Multi Threaded Programmierung hat das hohe Ziel selbst schlecht programmierte Software ohne Risiken ablaufen zu lassen.
Durch einen Garbage-Collektor wird ein Programm nicht besser. Eher im Gegenteil.
Sicherlich wird es für einige, die nicht mit Pointern umgehen können, das Programmieren einfacher. Solch einfach strukturierten Entwickler sind aber sowie wohl mehr eine Zeitbombe. Glaub man nicht, das ein Programm auf .NET keine Fehler verursachen kann..NET wird summarum das 'Basic' der neuzeit
meiner Meinung nach werden JAVA und .NET nur zur Waffe der Anfänger.
-
AndreasW schrieb:
Zumal sich die COM- Strategie in "Netzwerkkäse" mit vielen Türen als Fehler erweist. Oder würdest du ohne weiteres einfach ein ActiveX- Plugin in deinem Browser runterladen?
Was hat denn ein ActiveX im Browser mit COM zu tun, außer daß ActiveX als Basisprotokoll COM verwendet?
Interprozeßkommunikation mit COM ist doch wohl eine der wirklich eleganteren Sachen gewesen, die in den letzten Jahren eingeführt wurden. Und 99% aller Anwendungen, die COM benutzen, eröffnen keine Sicherheitslöcher, weil das einfach zwei Klassen sind, die miteinander kommunizieren. Das ist so sicher oder unsicher wie in einer einzigen Applikation. COM ist einfach eine Klasse ohne Daten mit lauter virtuellen Funktionen, die von einer abstrakten Basisklasse abgeleitet wurde, und statt selbst ein new zu machen, läßt man das von einer zusätzlichen Funktion erledigen. Das alleine macht noch gar nichts.
Die Gleichsetzung ActiveX mit COM ist im Jahre 2003 wirklich nicht mehr vertretbar, das galt am Anfang, als ActiveX neu war und herauskam, aber COM hat sich sehr weit davon entfernt. ActiveX ist ein Entwicklungszweig, der COM benutzte, und dessen Schnittstellen Sicherheitslöcher eröffnet haben. Ich halte das aber technisch für sehr verwegen argumentiert, dies COM anzulasten.
-
Kane schrieb:
schlechte Erfahrungen gemacht ?!?!?
Was die absolutistische Auffassung von MS was Standards angeht: JA!
Was das Verhalten von MS gegen über .Net "Immitaten" (.Gnu, Mono) angeht: JA!Oooo.., es tut mir leid für Dich.
Obwohl es nicht dem Thema entsprecht wurde mich aber interessieren in wie fern ??
Es ist doch perfekt
-
Durch einen Garbage-Collektor wird ein Programm nicht besser. Eher im Gegenteil.
Sicherlich wird es für einige, die nicht mit Pointern umgehen können, das Programmieren einfacher. Solch einfach strukturierten Entwickler sind aber sowie wohl mehr eine Zeitbombe. Glaub man nicht, das ein Programm auf .NET keine Fehler verursachen kann.klingt sehr nach: das haben wir frueher nicht so gemacht, warum sollten wir es heute machen
ich bin auch nicht der grosse fan der GC
aber das system ermoeglicht grosse moeglichkeiten und bei vielen tools, kleinen anwendungen und auch im server bereich kann ich mir schon erlauben mal mit GC zu arbeiten, speziell seitdem sie sich sehr stark verbessert haben
klassisches GC mit reinem referenz zaehlen gibt es ja fast nicht mehr
und in java hast du die auswahl aus (ich glaube) 4 standard GC
die alle fuer verschiedene bereiche gemacht worden sindich schaetze das sich der siegeszug der GC weiter fortsetzen wird
und das ist auch gut so
weil du willst nicht fuer jedes kleine programm einen spezialisten mit 3-5 jahren C++ erfahrung anstellen der dir dann ein bug freies projekt mit C++ erstellt
da nimmst du dir lieber einen 2-3 jahre erfahrenen entwickler in java oder C# und laesst ihn das machen
kommt billiger, geht (wahrscheinlich) schneller und die maintenance sollte auch kleiner seinauf der anderen seite wird man weiter fuer viele projekte C++ und andere sprachen brauchen -
man kann mit jeder software fehler verursachen
egal wie geschriebengomberl
-
Wenn sich dotNET durchsetzt dann wird programmieren ziemlich langweilig.
-
Hmmm...ist es denn sicher, dass C# kommen wird? Beispielsweise die Nachfrage an
Lehrbuechern fuer C# ist so gut wie gar nicht da, denn (ich kanns jetzt nur von
der Buecherrei in Bonn - Bouvier - sagen) hat letztens (oder noch) IT Buecher
ausgemistet. Darunter sehr sehr viele C#-Buecher.Offensichtlich, ist die Nachfrage nach dieser Sprache nicht besonders hoch. Ich
rede hier nicht von einem kleinen Buchladen, Bouvier is riesig. Hat denn diese
Sprache die nicht so gut angenommen wird, wovon ich jetzt einfach mal ausgehe,
sonst wuerden die Buecher ja nicht ausgemistet werden, ueberhaupt noch eine
Chance sich durchzusetzen, wenn nicht jetzt?Wuerd mich mal interessieren.
mfg
v R
-
AndreasW schrieb:
meiner Meinung nach werden JAVA und .NET nur zur Waffe der Anfänger.
Und was benutzen die anderen?
-
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.