Ich nehme alles zurück
… und behaupte das Gegenteil über C# und .Net – Microsoft wäre wirklich nicht Microsoft, wenn sie bei dieser Umgebung nicht noch einen, sondern gleich duzende draufgelegt hätte. Und sie haben einiges draufgelegt: Das Sicherheitskonzept lässt mich ja bekanntlich keine Programme über das Netz mit Zugriff auf den lokalen Computer starten (also weder Dateien noch Geräte), nein sogar auf Programmebene haben sie überraschende Trennwände eingezogen: Alle Elemente/Controls/Objekte einer GUI gehören ausschließlich dem GUI-Thread und andere Threads dürfen nicht darauf zugreifen. Das führt u. a. zu folgendem Standardbeispiel der Sorte „Was ist denn hier los?“
Unerwarteter Zugriffsschutz
Wir basteln uns ein Programm mit grafischer Benutzerfläche und fügen einen seriellen Port als Unterobjekt des Mainforms hinzu. In seinem Eventhandler, der jedesmal aufgerufen wird, wenn der Port Daten empfangen hat, wollen wir diese Daten z. B. in einer Textbox darstellen lassen. Obwohl der serielle Port dem Fenster gehört, läuft der Eventhandler in einem eigenen Thread und darf daher nicht auf die GUI-Elemente zugreifen. Ja, das macht nicht nur bei Programmen, die als eine Art „Server“ an der seriellen Schnittstelle lauschen Spaß, weil sie sofort beim Eintreffen von Daten abstürzen, sondern vor allem die Fehlersuche gestaltet sich ob der „aussagekräftigen Fehlermeldung“ sportlich. Anstelle einer kruden Meldung sollte der Microsoft-Compiler vielleicht einfach nur den Namen der Exception und die passende Manualseite ausgeben.
Apropos aussagekräftige Fehlermeldung: Wer errät, was der Compiler mit einer „Überlast“ meint? Tipps bitte in die Kommentare, wer richtig rät, gewinnt!
Nichts zu tun?
Mit meinem vorletzten Punkt für heute lehne ich mich zwar aus dem Fenster, aber mit Sicherheit nicht sehr weit. Wie weit kann es eigentlich mit der Performance der CIL hersein, wenn „der halbe Programmcode“ aus NOP besteht? Der folgende Screenshot zeigt ein Beispiel, und meine C#-.Net-Programme hatten noch mehr NOP, praktisch in jeder Methode:
Objekt- und Java-Orientierung
Obwohl die Programmiersprache C# ein „C“ im Namen trägt, sind die Gemeinsamkeiten mit Java und Unterschiede zu C++ nicht zu übersehen. In welcher Programmiersprache ist folgendes Hallo-Name-Programm geschrieben?
using System;
class Hallo {
static void Main() {
Console.Write("Name: ");
string name = Console.ReadLine();
Console.WriteLine("Hallo " + name);
}
}
Ein cooles Feature von C# ist die Objektinstanzierung mit Literalen, also z. B. 23.ToString(), was weder mit C++ noch Java, dafür aber der Mutter Smalltalk möglich ist. Schön wäre es noch, wenn man Arrays und Listen auch mit „einer Form von Literalen“ initialisieren könnte. Weniger cool ist hingegen die Schreibarbeit und das strikte Festhalten an der Objektorientierung:
- Man muss vor jedes Attribut und jede Methode, die nicht privat ist, einen Zugriffsmodifier schreiben. Und mit dem fehlenden Präprozessor lernt man das stupide Verfassen langer switch-case-Blöcke wieder schätzen.
- Es gibt weder globale Variablen noch „einfache Funktionen“, man muss sich also in solchen Fällen Pseudoklassen bauen, die nichts außer einem Haufen statischer Funktionen enthalten.
Hm. Irgendwie schieße ich mir doch lieber in den Fuß, anstatt durch einen pingeligen und fetten Oberaufseher ständig daran gehindert zu werden, „das darfst du nicht.“
