Warum soviele Strings?

[Artchi]

Die ATL zu benutzen ist nicht schlecht. Wenn jemand ActiveX-Komponenten in C++ enwickelt, und ATL dafür benutzt, ist das sogar sehr schlau. Weil einfacher geht es nicht. Über die WTL kann man aber streiten. Da tut es meiner Meinung nach die MFC dann besser. Außerdem ist die Frage, wie alt denn die Projekte schon sind, an denen du bastelst? Habe hier noch Kollegen die proggen in COBOL. Wird hier auch nie aussterben in der Firma. IBM hält wegen uns das eigentlich schon tot sein müssende CICS am Leben...

zu .NET:

Im Grunde kann doch jeder in .NET die Programmiersprache einsetzen wie er will. Allerdings wird ja dann ein Zwischencode erzeugt, der wiederum Geschwindigkeitsnachteile hat. Sind das ähnliche Geschwindigkeitseinbußen wie bei Java?

Ja, es gibt für die .NET-Plattform mehrere Sprachen, z.B. C#, Ruby, Python, VisualBasic und natürlich C++/CLI.
Die Performance dürfte sich auf dem Level von der Java Plattform bewegen. Ich hatte schon mal einen Performancetest gemacht: Java vs. C# vs. C++. Also, das war auf Arbeit eher Spaß, weil wir drei Fan-Fraktionen waren. Das C++-Programm hat mit ca. 4 Sekunden, ggü. den Java und C# mit 19 Sek. gewonnen. Komischerweise hat sowohl Java 1.5 als C# auf .NET 1.1 genau 19 Sek. gebraucht. Auch wenn jetzt die Javaner sturm laufen werden... Wer Performance über alles will, muß halt C++ oder eine andere Sprache nehmen, die echten Maschinencode erzeugt. Sonst würde die Games-Indutrie schon lange von C++ weg sein.

Ist es möglich ohne den Zwischencode zu programmieren, so dass man in C++ dann auch die volle Performance hat?

Wenn du keinen Zwischencode hast, hast du ja auch keine VM mehr und somit kein .NET oder kein Java. Deshalb verstehe ich die Frage nicht so ganz. Willst du C++/CLI machen? Da kannst du natürlich sagen: "Den Teil der Performance braucht, mach ich in nativen C++, und den Rest in C# oder C++/CLI." Du kannst sogar C++ und C++/CLI innerhalb einer Programmzeile mixen. Das ist hammer genial, kann aber einen ungeübenten C++ler verwirren.

Wie sieht das Java (ich glaube J++) genau für .NET aus? Das wird ja nicht genau das gleiche wie von Sun sein, oder?

Habe J# (oder J++?) noch nie benutzt. Aber meines Wissens ist es ja nur die Sprache Java, die Library ist natürlich weiterhin .NET. J# würde ich nicht machen, würde ich lieber C# lernen.

- Hast Du vielleicht nen Link, wo man zu solchen Fragestellungen etwas erklärt bekommt. Find ich echt interessant und ich will vor allem gut informiert sein, wenn es um die Planung der zukünftigen Entwicklungsumgebungen geht!

Geh doch einfach mal auf die http://www.msdn.com/ da gibts unmengen an Beiträgen zu .NET, C# und C++/CLI. Im Magazin-Forum haben wir meines Wissens auch noch einen .NET-Artikel.

Noch als Hinweis: du kannst .NET-PRogramme eigentlich sogar unter Linux laufen lassen: http://www.go-mono.com Muß man aber schauen, was man machen will.

[plizer]

C# mit .NET habe ich schon genutzt. Der Umstieg ging sehr schnell von Java. Nach ca. 1-2 Wochen war ich schon recht fix und nach dieser Zeit deutlich effektiver als jetzt nach 3-4 Monaten in C++ ;-). C# ist halt Java sehr nahe nach meiner Erfahrung.

Der Vorteil von Java-Programmierern wäre ja die bereits bekannte Bibliothek. Da würde ich dann auch lieber C# statt J# (so heisst es richtig) nehmen. Ein wichtiger Vorteil von .NET wäre sich der Einsatz von bereits entwickelten activeX-Elementen.

Werd mich mal bei den genannten Links umschauen, thx!

[tntnet]

Artchi schrieb:

IBM hält wegen uns das eigentlich schon tot sein müssende CICS am Leben...

Nicht nur wegen euch hält IBM CICS am leben. Auch bei uns wird das verwendet.

[Konrad Rudolph]

plizer schrieb:

Allerdings wird ja dann ein Zwischencode erzeugt, der wiederum Geschwindigkeitsnachteile hat.

Das ist so einfach falsch. Wie hier mehrheitlich gesagt worden ist, *ist* .NET zwar langsamer als z.B. reines C++ (je nachdem, was man macht). Mit dem Zwischencode hat das aber nichts zu tun. Das Overhead durch die Just-in-time-Kompilierung kann man bei solchen Vergleichen nicht mitzählen, zumal es ja die Möglichkeit der Vorkompilierung und des Caching im GAC gibt. Man kann sehr gut argumentieren, dass der Zwischencode die Ausführung sogar schneller macht, da er eine maschinenspezifische Optimierung des Codes erlaubt.

Die Geschwindigkeitseinbußen von .NET resultieren vielmehr darin, dass hier eben Referenztypen für Klassen verwendet werden, dass über alle Maßen viele virtuelle Funktionen eingesetzt werden, dass generell jede Menge hin und her gecastet wird und dass große Teile des Frameworks einfach nur lahm sind. Das .NET-Framework und die CLI sind eben, im Gegensatz zu C++, nicht mit Hinblick auf die Geschwindigkeit designed worden.