Grundlegende Fragen zu .Net

[Martin Schulze]

Hallo ich schreibe z.Zt. eine Studienarbeit über die Migration von VB 6 nach VB.net und habe einige Fragen die mir während einiger Bücher aufgekommen sind:

1. Machen verschiedene .Net-Programmierpsrachen überhaupt Sinn (mal abgesehen von Gewohnheit)? Alle greifen auf das/dieselbe zu also gibt es doch eigentlich keine Unterschiede (außer Syntaktischen) ? (etwas unpräzise Frage aber vielleicht kann jemand mal etwas weiter ausholen warum es doch Unterschiede gibt)

2. Es gibt einige Unterschiede zwischen den .Net-Sprachen z.B. uint-Datentyp bzw. Zeiger in C#, welche es in VB.net nicht gibt. Wenn diese Bestandteile von .net sind wie kann ich trotzdem mit VB.net darauf zugreifen, bzw. gibt es keine Probleme (und warum nicht?) wenn Komponenten aus anderen Sprachen diese Sachen benutzen und ich diese Komponenten in VB.net Projekte einbinden will?

3. gibt es durch die dynamische "Kompilierung" merkliche Perfomanceunterschiede im Vergleich zu den früheren Programmiersprachen bzw. kennt jemand eine Seite wo es dazu genauere Infos gibt?

Ich bin für jede Antwort/Link dankbar!
Gruss Martin

[Andreas Kosch]

Hallo,

zu Frage 1: Ja. Man könnte hier stundenlange Diskussionen führen, aber ich beschränke mit nur auf 2 Hauptargumente.

1. Freizügigkeit: <br>
a) Managed C++: Der "alte" Standard sorgt dafür, dass Änderungen/Erweiterungen nur sehr schwerfällig umsetzbar sind<br>
b) C#: Wurde von Microsoft ebenfalls zur Standardisierung eingereicht und kann daher nur nach Abstimmung geändert werden <br>
c) VB.NET: Sprache, die zukünftig frei erweitert/geändert werden kann, ohne auf Regelwerke (Standards) Rücksicht nehmen zu müssen.

2. Leistungsumfang: <br>
a) C#: Zeiger + unsafe Code, aber dafür keine implizite späte Bindung <br>
b) VB.NET: Keine Zeiger, aber dafür implizite späte Bindung und spürbare Erleichterungen innerhalb von Visual Studio .NET<br>
c) Managed C++: Portieren der Unmengen von C++ Anwendungen<br>
(in VB.NET steht die Einfachheit im Vordergrund, während C# die Leistungsfähigkeit als primäres Ziel hat).

Selbstverständlich gilt auch das Argument, dass die Mehrheit der Entwickler ja nicht völlig neu beginnt, sondern von einer "alten" Sprache her zu .NET wechselt. Um die Umstellungshürde so flach wie möglich zu halten, macht es hier sinn, die ersten Schritte mit einer "ähnlichen" .NET-Sprache zu beginnen.

zu Frage 2: Ja - jede .NET-Sprache darf eigene Erweiterungen umsetzen. Das Ergebnis ist nur dann kompatibel, wenn die Beschränkungen der Common Language Specification (CLS) beachtet werden. Dies gilt aber nur für die öffentlichen Schnittstellen (Rückgabewert, Parameter usw.) dieser Klasse - die interne Umsetzung der einzelnen Methoden unterliegt keinen Einschränkungen.

zu Frage 3: Ja. Jeder JIT-Compiler kann im Gegensatz zu den klassischen Compilern die folgenden Vorteile ausnutzen: <br>
1. Anzahl der CPUs steht zum Programmstart fest - der JIT-Compiler kann daher die MSIL-Anweisungen effektiv auf alle CPUs aufteilen. <br>
2. Typ der CPU steht zum Programmstart fest - der JIT-Compiler kann daher zu Prozessor-spezifischen Optimierungen greifen. Ein klassischer Compiler optimiert im besten Fall für den Pentium I. <br>
3. Speicheradressen stehen fest - kein Hantieren mit RVA-Tabellen, um die tatsächlichen Adressen erst zur Laufzeit aufzulösen. <br>
4. Inline-Funktionen nutzen, um den Aufruf von Methoden oder anderen Klassenbibliotheken über eine Abkürzung unnötig zu machen. <br>
5. usw.<br>

Im .NET Framework SDK ist das Tool <i>CLR Test Debugger Shell</i> (cor*dbg.exe) zu finden, dort kann man über den Modus <b>mode jit 1</b> und <b>mode jit 0</b> die Optimierung des JIT-Compilers Ein- und Ausschalten, um sich selbst von den Performance-Unterschieden zu überzeugen.

P.S: Borland (ist seit Jahr für seine schnellen Pascal/Delphi-Compiler bekannt) hat auf der letzten Entwicklerkonferenz in der USA eingeräumt, dass der JIT-Compiler von .NET sowohl schnelleren als auch effektiveren Code generiert. In meinem demnächst erscheinenden Buch sind einige Beispiele für den Performance-Vergleich zwischen Delphi 7 und VB.NET/C# zu finden. Das Ergebnis sieht für Delphi 7 unter einem Pentium 4 nicht gut aus :-)
&#10