In diesem Artikel werde ich im Detail erklären, warum man auch als VB.Net-Programmierer etwas mit C#-Codes anfangen kann, und worauf man beim Übersetzen achten muss.
Parallelen zwischen VB und C#
Zunächst einmal betrachten wir den "Unterbau" der beiden Sprachen - das .Net-Framework. Dieses wurde von Microsoft entwickel, um Softwareentwicklern das Leben zu erleichtern und eine einheitliche Programmumgebung zu schaffen. Demzufolge müssen sich alle Sprachen, die auf dem Framework basieren, an gewisse Vorschriften halten.
Die wichtigste davon ist die CLR-Kompatibilität. Die CLR (Common Language Runtime) ist die Runtime, die alle .Net-Programme ausführt. Sie garantiert einige Hilfreiche Features wie Plattformunabhängigkeit und Garbagecollection. Eine Sprache ist genau dann CLR-kompatibel, wenn sie ein CLR-kompatibles Typsystem besitzt, also nur Typen (Klassen, Strukturen, usw.) erlaubt, die die CLR verwalten kann. Dies hat den großen Vorteil, dass alle Sprachen, die für die CLR entwickelt wurden, auch untereinander kompatible Typsysteme besitzen, also alle Typen auch allen anderen Sprachen frei zugänglich sind. Ich kann also eine in C# geschriebene Klassenbibliothek ganz normal in eine VB-Anwendung einbinden und alle dort enthaltenen Klassen ganz genauso nutzen, wie die Klassen aus der eigenen Anwendung. Tatsächlich wird man im Studio nicht mal bemerken, dass es keine VB-Lib ist bzw. man kann nicht unterscheiden, ob eine Anwendung in C# oder VB geschrieben wurde.
Dieses Verhalten liegt an der nächsten Eigenart des Frameworks. Alle Sprachen, die darauf basieren, werden nach einem Klick auf "Kompilieren" in eine Einheitssprache namens "MSIL" (Microsoft Intermediate Language) umgewandelt. Tatsächlich ist dies eigentlich die einzige Sprache, mir der die CLR etwas anfangen kann, alle anderen Sprachen werden also nur CLR-kompatibel, weil sie nach MSIL übersetzt werden. Diesen ILCode kann man noch lesen und teilweise auch wieder in eine Ausgangssprache rückübersetzen (wie z.B. ILSpy das macht). Da dieser ILCode nach dem Übersetzen von VB und C# (und auch allen anderen .Net-Sprachen) aber identisch aussieht, bedeutet das natürlich, dass man z.B. einen aus C# entstanden ILCode auch nach VB umwandeln kann und umgekehrt.
Ein weiterer Vorteil von .Net-Sprachen ist, dass sie alle die gleiche Klassenbibliothek verwenden, nämlich die das Frameworks. Aufgrund dessen werdet ihr in einem C#-Code die selben Klassen- und Funktionsnamen wiederfinden, wie in einem VB-Code.
Dann gibt es noch einen weiteren Vorteil speziell für C# und VB. Beides sind objektorientierte, imperative Sprachen, was sie in ihrer logischen Struktur sehr ähnlich macht. Das heißt, C# definiert seine Klassen vom Aufbau her genauso wie VB.
Zusammen mit den oben genannten Dingen sorgt dies dafür, dass sich die zwei Sprachen bis auf die Syntax fast komplett gleichen, also 1zu1 übersetzt werden können. Dies sieht man daran, dass es einige automatisierte Verfahren zur Übersetzung zwischen den beiden Sprachen in Form von Onlineconvertern gibt. Bei Sprachen wie C++ und Delphi z.B. wäre dies nicht möglich.
Einen solchern Converter findet ihr beispielsweise hier: codeconverter.sharpdevelop.net/SnippetConverter.aspx
Unterschiede zwischen VB und C#
Genug der Theorie, nun werde ich die wichtigsten Unterschiede zwischen VB und C# nennen. Wenn ihr diese Tipps hier befolgt, dann solltet ihr in der Lage sein, 99% aller C#-Codes nach VB zu übersetzen.
Syntax
Zunächst einmal wäre da natürlich die Syntax. Wären VB.Net sich am alten VB6 und/oder VBA orientiert, übernimmt C# viele Elemente aus C/C++.
Ich kann hier nicht die komplette Syntax von C# erklären, aber ich werde einige signifikante Punkte besprechen.
Schlüsselwörter
VB und C# unterstützen die gleichen Modifizierer, jedoch heißen sie unterschiedlich. Es folgt nun eine List im Stil
Events
Einen sehr großen Unterschied weisen VB und C# im Umgang mit Events auf. Ich werde nun erst einmal erklären, was ein Event überhaupt für den Computer darstellt.
Ein Event ist zunächst ein einfacher Delegat. Ein Delegat kann man sich grob als eine Ansammlung von Zeigern auf Methoden/Funktionen vorstellen. Wenn man einen Delegaten aufruft, dann ruft man im Prinzip nur alle Methoden/Funktionen auf, auf die der Delegat zeigt. Delegaten sind somit .Nets Functionpointer (bekannt aus C++). Wenn wir ein Event abonnieren, dann fügen wir dieser Liste eigentlich nur den Zeiger auf eine Methode/Funktion hinzu. VB verschleiert diesen Prozess, um es einsteigerfreundlicher zu machen, indem die Schlüsselwörter
Events sind meinst von Delegatentyp
Angenommen wir haben diese Eventdeklaration:
Dann würden wir mir diesem Code in VB das Event abonnieren und deabonnieren:
Dabei holen wir uns den Zeiger zu der Methode mit dem AddressOf-Schlüsselwort.
C# kennt kein solches Schlüsselwort. Stattdessen können wir gleich die Methode selbst dem Delegaten hinzufügen. Dies geschieht mit den Operatoren
Beachtet hier die Schreibweise ohne Klammern. Die Klammern stehen in C# für einen Aufruf, werden sie weggelassen so wird der Zeiger angesprochen.
Beachtet auch, dass man in C# vor dem Aufrufen eines Events dieses immer auf
wird zu
Lambda
VB und C# unterstützen beide Lambda, also sogenannte
VB verwendet zum deklarieren solcher anonymer Methoden die selben Schlüsselwörter, wie bei den nichtanonymen:
oder mehrzeilig
In C# schreibt man einfach nur die Argumente gefolgt von einem
oder mehrzeilig
Achtung: wenn es nur ein Argument gibt, dann können in C# die Argumentklammern auch weggelassen werden.
Konstruktoren
In VB deklariert man einen Konstruktor, indem man eine Methode mit dem Namen
Da C# sich aber nach C richtet, ist der Konstruktor dort keine normale Methode, da sie keinen Rückgabetyp besitzt (auch nicht "void"). Außerdem trägt sie den Namen der Klasse.
Außerdem gibt es in C# noch einen sogenannten Destruktor, der in VB fehlt und aufgerufen wird, wenn das Objekt durch den Garbagecollector zerstört wird. Dessen Syntax ist identisch zu der des Konstruktors, mit der Ausnahme, dass vor den Namen noch ein
Eine ähnliche Funktionalität kann man in VB durch die Methode
Module
In VB gibt es Module, welche es erlauben, Methoden und Funktionen zu deklarieren, die man unabhängig von einer Klasse verwenden kann. Diese sind aber ein Überbleibsel aus VB6, weshalb sie keinen Einzug in C# gefunden haben. Dort verwendet man für diese Zwecke statische Klassen.
wird zu
Properties
Obwohl beide Sprachen Properties (Eigenschaften) unterstützen, verhalten sie sich hier doch etwas anders.
Währen in VB Properties auch Parameter besitzen können, ist dies in C# nicht ohne weiteres möglich. Dort muss man gegebenenfalls auf einen Getter und einen Setter zurückgreifen.
wird zu
Eine Ausnahme bildet der sogenannte Indexer, mit diesem sind auch in C# Argumente bei Properties möglich. Er entspricht der Default-Property aus VB und hat immer den Namen
wird zu
Aus C# würde er so aufgerufen werden:
In VB ist er zusätzlich noch unter dem Namen
Unsafe
C# besitzt einen sogenannten Unsafe-Block. Dieser erlaubt Zugriffe auf Pointer und fehlt in VB vollkommen.
Möchte man einen sochen nach VB.Net übersetzen, so gibt es leider keine einheitliche Vorgehensweise, hier ist der Einfallsreichtum des Programmierers gefragt. Hilfreich könnte Marshalling sein, vielleicht gibt es aber auch eine bessere Möglichkeit.
Da das Thema zu komplex für diesen Artikel wäre, werde ich es komplett außen vor lassen.
Wenn ihr noch weitere Beispiele/Vergleiche braucht, hier findet ihr eine große Liste (danke fichz).
Wenn ich noch was vergessen habe oder ich mich ungenau/unverständlich ausgedrückt haben sollte, so bitte ich darum mir dies mitzuteilen.
Parallelen zwischen VB und C#
Zunächst einmal betrachten wir den "Unterbau" der beiden Sprachen - das .Net-Framework. Dieses wurde von Microsoft entwickel, um Softwareentwicklern das Leben zu erleichtern und eine einheitliche Programmumgebung zu schaffen. Demzufolge müssen sich alle Sprachen, die auf dem Framework basieren, an gewisse Vorschriften halten.
Die wichtigste davon ist die CLR-Kompatibilität. Die CLR (Common Language Runtime) ist die Runtime, die alle .Net-Programme ausführt. Sie garantiert einige Hilfreiche Features wie Plattformunabhängigkeit und Garbagecollection. Eine Sprache ist genau dann CLR-kompatibel, wenn sie ein CLR-kompatibles Typsystem besitzt, also nur Typen (Klassen, Strukturen, usw.) erlaubt, die die CLR verwalten kann. Dies hat den großen Vorteil, dass alle Sprachen, die für die CLR entwickelt wurden, auch untereinander kompatible Typsysteme besitzen, also alle Typen auch allen anderen Sprachen frei zugänglich sind. Ich kann also eine in C# geschriebene Klassenbibliothek ganz normal in eine VB-Anwendung einbinden und alle dort enthaltenen Klassen ganz genauso nutzen, wie die Klassen aus der eigenen Anwendung. Tatsächlich wird man im Studio nicht mal bemerken, dass es keine VB-Lib ist bzw. man kann nicht unterscheiden, ob eine Anwendung in C# oder VB geschrieben wurde.
Dieses Verhalten liegt an der nächsten Eigenart des Frameworks. Alle Sprachen, die darauf basieren, werden nach einem Klick auf "Kompilieren" in eine Einheitssprache namens "MSIL" (Microsoft Intermediate Language) umgewandelt. Tatsächlich ist dies eigentlich die einzige Sprache, mir der die CLR etwas anfangen kann, alle anderen Sprachen werden also nur CLR-kompatibel, weil sie nach MSIL übersetzt werden. Diesen ILCode kann man noch lesen und teilweise auch wieder in eine Ausgangssprache rückübersetzen (wie z.B. ILSpy das macht). Da dieser ILCode nach dem Übersetzen von VB und C# (und auch allen anderen .Net-Sprachen) aber identisch aussieht, bedeutet das natürlich, dass man z.B. einen aus C# entstanden ILCode auch nach VB umwandeln kann und umgekehrt.
Ein weiterer Vorteil von .Net-Sprachen ist, dass sie alle die gleiche Klassenbibliothek verwenden, nämlich die das Frameworks. Aufgrund dessen werdet ihr in einem C#-Code die selben Klassen- und Funktionsnamen wiederfinden, wie in einem VB-Code.
Dann gibt es noch einen weiteren Vorteil speziell für C# und VB. Beides sind objektorientierte, imperative Sprachen, was sie in ihrer logischen Struktur sehr ähnlich macht. Das heißt, C# definiert seine Klassen vom Aufbau her genauso wie VB.
Zusammen mit den oben genannten Dingen sorgt dies dafür, dass sich die zwei Sprachen bis auf die Syntax fast komplett gleichen, also 1zu1 übersetzt werden können. Dies sieht man daran, dass es einige automatisierte Verfahren zur Übersetzung zwischen den beiden Sprachen in Form von Onlineconvertern gibt. Bei Sprachen wie C++ und Delphi z.B. wäre dies nicht möglich.
Einen solchern Converter findet ihr beispielsweise hier: codeconverter.sharpdevelop.net/SnippetConverter.aspx
Unterschiede zwischen VB und C#
Genug der Theorie, nun werde ich die wichtigsten Unterschiede zwischen VB und C# nennen. Wenn ihr diese Tipps hier befolgt, dann solltet ihr in der Lage sein, 99% aller C#-Codes nach VB zu übersetzen.
Syntax
Zunächst einmal wäre da natürlich die Syntax. Wären VB.Net sich am alten VB6 und/oder VBA orientiert, übernimmt C# viele Elemente aus C/C++.
Ich kann hier nicht die komplette Syntax von C# erklären, aber ich werde einige signifikante Punkte besprechen.
- Codezeilen in C# enden immer mit einem Semikolon. Dadurch wird es möglich, theoretisch beliebig viel Anweisungen in eine Zeile zu schreiben, da der Zeilenumbruch in C# im Gegensatz zu VB keine Bedeutung hat (macht euch darüber weniger sorgen, kein anständiger C#-Programmierer tut das).
- In C# gibt es keinen syntaktischen Unterschied zwischen einer Methode und einer Funktion. Eine Methode ist einfach eine Funktion, die
void
(zu Deutsch "nichts") zurückgibt.
wird zu
- Alle Anweisungsblöcke (Klassen, Funktionen, Schleifen, If-Abfragen, usw...) werden mit geschweiften Klammern eingeschlossen, anstatt wie bei VB mit einer End-Anweisung beendet.
wird zu
Es gibt allerdings eine Ausnahme bei If-Abfragen und Schleifen: wenn auf solche kein Klammernpaar folgt, so ist darauf folgene Anweisung die einzige, die sich innerhalb diese Blockes befindet. Ein ähnliches Konstrukt gibt es bei VB auch mit If.
normale Abfrage in VB:
kurze Abfrage in VB:
normale Abfrage in C#:
kurze Abfrage in C#:
- C# hat Klammerzwang hinter Parameterlosen Methoden/Funktionen.
wird zu
Wenn ihr diese Klammern weglasst, dann werdet ihr einen saftigen Fehler geworfen bekommen, da die Methode ohne Klammern in C# etwas ganz anderes bedeutet (siehe "Events").
- C# ist case-sensitive, das bedeutet, dass
test
undTest
etwas verschiedenes ist.
Dadurch sind z.B. solche Dinge möglich:
In VB würde diese Namensgebung Probleme machen. Ihr müsst dann gegebenenfalls den Namen der Variable ändern:
Schlüsselwörter
VB und C# unterstützen die gleichen Modifizierer, jedoch heißen sie unterschiedlich. Es folgt nun eine List im Stil
<VB-Name> - <C#-Name>
.- Friend - internal
- Shared - static
- Overrides - override
- Overrideable - virtual
- MustOverride - abstract
- MustInherit - abstract
- NotInheritable - sealed
Events
Einen sehr großen Unterschied weisen VB und C# im Umgang mit Events auf. Ich werde nun erst einmal erklären, was ein Event überhaupt für den Computer darstellt.
Ein Event ist zunächst ein einfacher Delegat. Ein Delegat kann man sich grob als eine Ansammlung von Zeigern auf Methoden/Funktionen vorstellen. Wenn man einen Delegaten aufruft, dann ruft man im Prinzip nur alle Methoden/Funktionen auf, auf die der Delegat zeigt. Delegaten sind somit .Nets Functionpointer (bekannt aus C++). Wenn wir ein Event abonnieren, dann fügen wir dieser Liste eigentlich nur den Zeiger auf eine Methode/Funktion hinzu. VB verschleiert diesen Prozess, um es einsteigerfreundlicher zu machen, indem die Schlüsselwörter
AddHandler
und RemoveHandler
eingefürt wurden.Events sind meinst von Delegatentyp
Eventhalndler
können aber theoretisch von jedem Delegatentyp sein.Angenommen wir haben diese Eventdeklaration:
Dann würden wir mir diesem Code in VB das Event abonnieren und deabonnieren:
C# kennt kein solches Schlüsselwort. Stattdessen können wir gleich die Methode selbst dem Delegaten hinzufügen. Dies geschieht mit den Operatoren
+
und -
.Beachtet hier die Schreibweise ohne Klammern. Die Klammern stehen in C# für einen Aufruf, werden sie weggelassen so wird der Zeiger angesprochen.
Beachtet auch, dass man in C# vor dem Aufrufen eines Events dieses immer auf
null
prüfen muss, falls noch keine Zeiger hinzugefügt wurden. VB übernimmt dies für einen.wird zu
Lambda
VB und C# unterstützen beide Lambda, also sogenannte
anonyme Methoden
. Die Syntax unterscheidet sich aber so deutlich, dass ich es hier ebenfalls bespreche.VB verwendet zum deklarieren solcher anonymer Methoden die selben Schlüsselwörter, wie bei den nichtanonymen:
oder mehrzeilig
In C# schreibt man einfach nur die Argumente gefolgt von einem
=>
an diese Stelle:oder mehrzeilig
Achtung: wenn es nur ein Argument gibt, dann können in C# die Argumentklammern auch weggelassen werden.
Konstruktoren
In VB deklariert man einen Konstruktor, indem man eine Methode mit dem Namen
New
erstellt. Dies ist für Einsteiger vermutlich leichter, da Objekte ebenfalls mit New
erzeugt werden und man somit sieht, dass dann diese Methode aufgerufen wird.Da C# sich aber nach C richtet, ist der Konstruktor dort keine normale Methode, da sie keinen Rückgabetyp besitzt (auch nicht "void"). Außerdem trägt sie den Namen der Klasse.
Außerdem gibt es in C# noch einen sogenannten Destruktor, der in VB fehlt und aufgerufen wird, wenn das Objekt durch den Garbagecollector zerstört wird. Dessen Syntax ist identisch zu der des Konstruktors, mit der Ausnahme, dass vor den Namen noch ein
~
gesetzt wird.Eine ähnliche Funktionalität kann man in VB durch die Methode
Finalize
erreichen, die laut MS der offizielle Ersatz für den Destruktor ist.Module
In VB gibt es Module, welche es erlauben, Methoden und Funktionen zu deklarieren, die man unabhängig von einer Klasse verwenden kann. Diese sind aber ein Überbleibsel aus VB6, weshalb sie keinen Einzug in C# gefunden haben. Dort verwendet man für diese Zwecke statische Klassen.
wird zu
Properties
Obwohl beide Sprachen Properties (Eigenschaften) unterstützen, verhalten sie sich hier doch etwas anders.
Währen in VB Properties auch Parameter besitzen können, ist dies in C# nicht ohne weiteres möglich. Dort muss man gegebenenfalls auf einen Getter und einen Setter zurückgreifen.
wird zu
Eine Ausnahme bildet der sogenannte Indexer, mit diesem sind auch in C# Argumente bei Properties möglich. Er entspricht der Default-Property aus VB und hat immer den Namen
this
.Aus C# würde er so aufgerufen werden:
In VB ist er zusätzlich noch unter dem Namen
Item
wie eine normale Property verfügbar:Unsafe
C# besitzt einen sogenannten Unsafe-Block. Dieser erlaubt Zugriffe auf Pointer und fehlt in VB vollkommen.
Möchte man einen sochen nach VB.Net übersetzen, so gibt es leider keine einheitliche Vorgehensweise, hier ist der Einfallsreichtum des Programmierers gefragt. Hilfreich könnte Marshalling sein, vielleicht gibt es aber auch eine bessere Möglichkeit.
Da das Thema zu komplex für diesen Artikel wäre, werde ich es komplett außen vor lassen.
Wenn ihr noch weitere Beispiele/Vergleiche braucht, hier findet ihr eine große Liste (danke fichz).
Wenn ich noch was vergessen habe oder ich mich ungenau/unverständlich ausgedrückt haben sollte, so bitte ich darum mir dies mitzuteilen.
Dieser Beitrag wurde bereits 10 mal editiert, zuletzt von „Artentus“ ()