C# vs Delphi.net - Vor- und Nachteile

**Heffalump**

Zitat von Pr0g:

Hallo,

ich habe mich noch nicht so viel mit .Net beschäftigt und es erstmal auch nicht vor...

.Net ist die Zukunft, was mindestens die Programmierung für Windows bedeutet. Du kannst den Zug verpassen oder aufspringen. Ich habe für mich beschlossen aufzuspringen und programmiert wird C#. Mir gefällt zwar die Übersichtlichkeit nicht so gut wie die von Pascal, aber wie hier bereits erwähnt, gibt es sehr viele Beispiele zu .Net und diese sind in C# geschrieben.

Hat sich zudem mal jemand das kompilierte Ergebnis in der Delphi IDE angesehen (siehe Beispiel)? Ich frage mich, was die Pascal Delphi Version aus den Namensräumen macht und was da noch so auftaucht ohne das man es wollte (Da steht was von VCL, obwohl es ein WinForm Projekt ist). Zudem habe ich den ein oder anderen Fehler gefunden, der sich so in anderen IDEs nicht nachvollziehen läßt. Zum Beispiel funktionieren diese

Schaltflächen nicht, im Gegensatz zu SharpDevelop 1.1, 2.0 und Visual Sharp Express.

**Pr0g**

Zitat von Heffalump:

.Net ist die Zukunft, was mindestens die Programmierung für Windows bedeutet. Du kannst den Zug verpassen oder aufspringen.

Ich halte es noch für zu früh und werde weiterhin Win32 nutzen. Nach dem Release von Vista und einiger dann vergangener Zeit evtl. .Net, so zumindest die aktuelle Planung. Aber das soll nicht Thema dieser Diskussion werden

**Phoenix**

Also das mit dem .NET 2.0 hat sich dank Daniel's experimentierfreudigkeit ja schon gelegt: Auch der Delphi-Compiler aus dem BDS 2006 kann gegen .NET 2.0 kompilieren.

Und .NET ist .NET - egal welche Sprache Du verwendest. Wenn ich mal kurz einen Prototypen ausprobieren will tippe ich den in C# runter, meine Projekte sind aber immer imho besser lesbarer Delphi.NET - Code. Hat bei mir Gründe der Wartbarkeit und der Übersichtlichkeit. Wenn C# auch Forward-Deklarationen hätte *träum*....

Vor- und Nachteile? Nunja, Delphi hinkt etwas hinterher. Auch wenn man mit Tricks schon mit .NET 2.0 arbeiten kann so ist das doch ein gefrickel.

Bei der Umstellung von Delphi/VCL -> .NET hast Du schon einen batzen vor Dir. Wenn Du Dir gleichzeitig noch die Umgewöhnung von Delphi Language -> C# antun willst ist das schon ein ganz grosser Brocken. Dann solltest Du aber noch die Umstellung von Delphi/BDS -> Visual Studio mitnehmen, und die ist zum einen für einen Delphianer arg Gewöhnungsbedürftig. Weil mit C# auf dem BDS zu bleiben... dann kannst Du genausogut Delphi.NET nehmen, weil C# im BDS bietet Dir keine Vorteile sondern eher nur das Hinterherhinken als Nachteil gegenüber dem VS.

**hanspeter**

Zitat von Pr0g:

Ich halte es noch für zu früh und werde weiterhin Win32 nutzen. Nach dem Release von Vista und einiger dann vergangener Zeit evtl. .Net, so zumindest die aktuelle Planung. Aber das soll nicht Thema dieser Diskussion werden

BDS und C#, sollte man sich nicht unbedingt antun. Da gibt es zu wenig Vorteile.
Ich wünsche mir heute noch ein System, welches plattformübergreifend compilieren könnte.
Und was Win32 angeht.
Solange MS seine eigenen großen Systeme, sprich Word,Excel,Access,SQL Server nicht auf Net umstellt, mach ich mir
um ein Sterben der Win32 API keine Gedanken. Die wird bestenfalls von einer Win64 API (teilweise) ersetzt.

Laufzeitverhalten ist da schon eher ein Kriterium und da dürfte ein Win32 Programm noch lange die Nase vorn haben.

Viel wichtiger ist eigentlich die Frage, wie es mit Delphi überhaupt weitergeht.
Borland hat mit seiner Verkaufsankündigung viele so verunsichert, das ich nur noch angelächelt werde, wenn ich bei einem angehenden Auftrag Delphi sage.
Gibt es da eigentlich schon was Neues, damit die diesbezügliche Lähmung aufhört?

Gruß
Peter

**Elvis**

Zitat von Phoenix:

Also das mit dem .NET 2.0 hat sich dank Daniel's experimentierfreudigkeit ja schon gelegt: Auch der Delphi-Compiler aus dem BDS 2006 kann gegen .NET 2.0 kompilieren.

Wenn man jetzt noch dagegenrechnet, dass man in fast jeder Klasse in 2.0 gegen generische Interfaces/Klassen programmiert kann man dn "Trick" als Spielerei abtun...

Zitat:

Hat bei mir Gründe der Wartbarkeit und der Übersichtlichkeit. Wenn C# auch Forward-Deklarationen hätte *träum*....

Um es in tommies art zu schreiben:
[ ] Du weißt was Forward declarations sind

Was du meinst ist eine Trennung von Interface & Implementierungs section.
FDs würd ich meinem schlimmsten Feind nicht zumuten wollen.
Das Hineinquetschen von mehreren voneinander abhängigen Typen in ein Code file halte ich für alles andere als wartbar oder lesbar.
Wenn du interface sections und/oder Pascal magst, kann ich nur Chrome empfehlen. D32 mag absolut KickAss für natives Entwickeln sein

, D.Net ist aber nur ein zusammengeriemeltes "Ding", das so hässlichen Code generiert, dass man den keinem non-Delphi .Net-Entwickler vorhalten könnte.

In D.Net gibt es immer noch Units, du kannst selbst keine Namespaces benutzen. Jeder D.Net-Konsument deiner Assemblies muss wieder deine Units verwenden.

Du hast keine Sichtbarkeitsmodifizierer für Typen, außer es sind nested types.

Da der Compiler sich nur wie ein frisierter D32 compler verhält wird er sowas hier ohne zu murren kompilieren:

zusammenfalten · markieren

Delphi-Quellcode:

			unit NS.A;

interface

type Class1 = class

end;

unit NS.B;

interface

type Class1 = class

end;

Natürlich hast du jetzt Class1 zweimal im namespace NS[1], wodurch die generierte Assembly nicht benutzbar ist...

Wer Pascal mag und Neuentwicklungen in .Net anfängt sollte sich IMHO erstmal Chrome ansehen, bevor er seine Zeit mit D.Net verschwendet um danach zu C# zu flüchten.
Es kann eigentlich alles was C# kann bis auf anonyme Methoden[2], aber halt pascalisch.

[1]Wer hier nicht hinterkam braucht sich nicht schämen, die Art wie D.Net Namespaces anlegt/benutzt ist kompliziert genug um ein ganzes Kapitel zu füllen.

[2]Bis jetzt gab es nicht einen Vorschlag wie die in Chrome aussehen könnten, der nicht absolut hässlich war.

**jbg**

Zitat von Pr0g:

Mit VCL.Net will ich garnet erst anfangen. Wenn dann schon komplett .Net. Muss man bei der VCL.Net nicht alles in zich Extradlls mitliefern...

Und was ist für dich dann "komplett .NET" ? Wenn du damit meinst, dass man keine Assemblies (aka DLL) braucht, dann gibt es kein "komplett .NET", denn auch ohne VCL.NET braucht man Assemblies. Und mit Delphi.NET kann man die Borland.*.dll Assemblies auch statisch in das Executable linken, womit diese auch nicht mehr ausgeliefert werden müssen.
Und wenn du nun mit dem P/Invoke "Problem der VCL.NET" ankommst, dann muss ich dir leider sagen, dass WinForms ebenfalls nur aus P/Invokes besteht, wobei man die nicht direkt sieht, weil Microsoft den Quellcode dazu nicht (wie Borland) mit ausliefert.

**Bernhard Geyer**

Zitat von jbg:

Und wenn du nun mit dem P/Invoke "Problem der VCL.NET" ankommst, dann muss ich dir leider sagen, dass WinForms ebenfalls nur aus P/Invokes besteht, ...

Das stimmt. Aber MS kann seinen Assemblies aus dem .NET-Framework einen "Full-Trust"-Stempel geben um die Performanceverluste von P/Invoke aufgrund von Sicherheitsüberprüfungen zu minimieren. Das kann Borland natürlich nicht.

**Elvis**

Zitat von Bernhard Geyer:

Zitat von jbg:

Und wenn du nun mit dem P/Invoke "Problem der VCL.NET" ankommst, dann muss ich dir leider sagen, dass WinForms ebenfalls nur aus P/Invokes besteht, ...

Das stimmt. Aber MS kann seinen Assemblies aus dem .NET-Framework einen "Full-Trust"-Stempel geben um die Performanceverluste von P/Invoke aufgrund von Sicherheitsüberprüfungen zu minimieren. Das kann Borland natürlich nicht.

Richtig. Ich kann einen smart client mit SWF schreiben. Der wird direkt über's Internet gestartet und da er keine lokalen Berechtigungen braucht, wird er direkt starten ohne den User irgendwas zu fragen und ihn somit verunsichern. Eine VCL.Net App wird schlichtweg mit einer SecurityEx wegsterben bevor auch nur ein einiziger Pixel erscheint (RuntimeSecurityException kann man nicht abfangen

).

Außerdem hat MS die .Net BCL/FCL nicht obfuscated, dadurch kann man mit dem Reflector wunderbar darin umhersurfen.

SWF ist im worst case archlahm, das ist richtig. Aber wenn CAS, DataBinding oder Kompatibilität zu den StiNo interfaces in .Net notwendig/erwünscht ist, ist VCL.Net schlichtweg keine Option.

**Pr0g**

Ich meinte es so, dass ich unter C# ja bspw. auch keine VCL habe, bzw. sie nicht dazugehört. Warum also die VCL Controls nutzen, wenn ich auch die aus .NET nutzen kann, welche nicht extra dazugeliefert werden müssen. Ob nun als DLL, oder reinkompiliert, die Datenmenge wird unnötig größer...

Habe mir nun mal Visual C# 2005 Express installiert und versuche nun ein Programm unter Linux/Mono zum laufen zu bekommen

**Phoenix**

Zitat von Pr0g:

Habe mir nun mal Visual C# 2005 Express installiert und versuche nun ein Programm unter Linux/Mono zum laufen zu bekommen

Holla. Mono ist im Bereich .NET 1.1 zwar schon recht gut, aber .NET 2.0 ist da bei weitem noch nicht vollständig. Und VS C# Express ist halt .NET 2.0. Da wirst Du einiges zu knabbern haben.