Ich möchte nochmal ein paar Dinge richtigstellen.
- Zeiger
Natürlich gibt es in .NET Zeiger. Die CLR mag sie nicht, aber in C# kann man sie problemlos in einem unsafe-Block verwenden. Mit kompletter C-Murks-Zeigerarithmetik und ohne Bereichsprüfungen.
- Assembly
Auch das gibt es. Nämlich in C++/CLI. Das verbindet .NET mit nativem Code, und im nativen Code kann man auch den Inline-Assembler verwenden. Es ist also kein Problem, performance-kritische Routinen in eine C++/CLI-Assembly auszulagern und sie dann aber von außen wie jedes andere .NET-Objekt zu benutzen. Da kommt man dann auch wieder an einen Punkt, wo es heißt: Für jedes Problem das passende Werkzeug.
- Performance
String.Format als Vergleich für das Delphi-Format anzubringen ist nicht wirklich sinnvoll. Ebensowenig das "Testprogramm", das da genannt wurde. Wenn ich in meinen Programmen mal schaue, wo die Performance fehlt, ist es äußerst selten eine BCL-Routine und ebensoselten ist es reines Numbercrunching. Meistens ist es ein Problem im Aufbau des jeweiligen Algorithmus. Also String.Format mit Delphi-Format in einer Schleife zu vergleichen und aufgrunddessen zu sagen, dass .NET langsamer ist, ist Blödsinn.
Und meine aktuelle Windows-Forms-Anwendung hat lediglich eine Schwäche beim Rendern einer komplexen Grafik, weil da sehr viele weiche Rundungen drin vorkommen (aber das ist Sache der GDI+ und hat nichts mit .NET zu tun). Alles andere ist auch nicht langsamer als bei einer typischen Delphi-Anwendung. Und selbst wenn es so wäre, wäre das vollkommen egal, weil die Anwendung 99% ihrer Zeit entweder auf den Anwender wartet oder auf die Drittanbieterkomponente, die das Backend darstellt und die eben einfach langsam ist (übrigens in C++ geschrieben...)
Die Tatsache, dass es eine rein .NET-basierte 3D-API für Windows und XBox360 gibt, zeigt doch, dass .NET auch performance-seitig ready for primetime ist. Und die ist sogar tatsächlich trotz GC sauschnell. Genau wie viele Beispiele aus dem DirectX SDK, die häufig in C# etwas schneller sind.
- Enumeratoren
Sind im Allgemeinen schnell und problemlos. Auf Desktop-Windows räumt der GC die Dinger recht schnell weg, dafür gibt es ja Generation 0. Beim Compact-Framework muss man etwas aufpassen, weil z.B. der GC der XBox360 keine Generationen unterstützt. Folglich sind die meisten Enumeratoren dort implizit Stack-Objekte.
Zitat:
Um mit .NET vernünftig arbeiten zu können, muss dieser Quellcode neu geschrieben werden, dass heißt man fängt wieder bei Adam und Eva an.
Nur wenn man natives Delphi oder Visual Basic ohne
COM für den alten Code verwendet hat. Hat man C++ oder
COM verwendet, ist eine Einbindung relativ unproblematisch. Und wenn alle Stricke reißen, gibt es auch noch P/Invoke und man kann damit auf alles zugreifen, was außerhalb von .NET liegt. Die Grundidee hinter .NET ist jedoch anders: Du kannst in einer beliebigen Sprache entwickeln und mit beliebigen Objekten in einer anderen Sprache zusammenarbeiten. Versuch mal, in Delphi eine in C++ geschriebene Klasse abzuleiten und du weißt, was ich meine.