Hallo,
einige von und haben ja mittlerweile einige Zeit in Delphi 8 investiert.
Ich stelle gerade eine Liste mit pro und kontra zu Delphi 8 zusammen.
Bitte beteiligt Euch, damit diese Liste noch etwas wächst.
Ich werde Eure Beiträge in diesen Text einarbeiten
Diese Liste kann dann auch bei Entscheidungen für oder gegen Delphi in Unternehmen genutzt werden.
credits:
teilweise sind Daten/Texte von delphipraxis.net, delphi-source.de und entwickler.de eingeflossen
Danke für die Infos.
Die fertige Liste wird den Seiten dann auch zur Verfügung gestellt.
Borland Delphi 8 for .net
pro- Es kann VCL.NET oder WinForms programmiert werden
- Eine Portierung von Anwendungen wird ohne großen Aufwand möglich, wenn
- nur Komponenten von Delphi verwendet werden, die auch in D8 zur Verfügung stehen
- in den D5 / D7 Projekten auf Pointer verzichtet wurde
- darauf geachtet wurde, dass keine bzw. wenig Warnungen und Hinweise beim Kompilieren erscheinen
- Quellcode ist für Delphi Programmierer gut lesbar. (da Object Pascal)
- keine Einarbeitungszeit in Syntax der Sprache (da Object Pascal)
- Es ist möglich DLLs zu erzeugen, die von .net und win32 benutzt werden können
- Delphi 8 unterstützt direkt Rational ClearCase (IBM)
- Es wird auch eine neue Version (v2) des Tools SourceConneXion für Delphi for .net geben
- Es können bei Migration VCL.NET und WinForms verwendet werden
- Delphi für .NET-Features, die nicht in C# verfügbar sind
- Kann Assemblies in eine Exe linken, ohne den Sourcecode für die Assemblies zu haben (unter Verwendung der Delphi-Package-Syntax)
- Funkionen in einer managed Delphi für .NET-Assembly kann direkt von unmanaged Win32 x86-Code ohne COM-Interop oder .NET-Dingen aufgerufen werden.
- Gespeicherte Symbol-Informationen für eine schnellere Compilierzeit
- Virtuelle Konstruktoren
- Benannte Konstruktoren
- Virtuelle Aufrufe von Klassenmethoden
- Ressourcenstrings
- Delphi ist natürlich nicht von Microsoft
- Delphi für .NET unterstützt versiegelte Klassen (sealed classes). Microsoft hat viele Klassen im .NET-Framework versiegelt, und sie bekommen viel mehr Kummer damit als Borland jemals mit privaten Membern bekommen hat, weshalb sie überlegen, einige davon zu öffnen. Allerdings bieten versiegelte Klassen einige Optimierungsmöglichkeiten für den JITer. Das gleiche gilt für finale Methoden.
- Source der VCL wird mitgeliefert !!!
- Kosten für Update auf D8 geringer als Neukauf VS.NET
- nur geringe "Ausfallzeiten", da Umgewöhnung auf neue Programmiersprache entfällt.
- VCL kann direkt wie gewohnt benutzt werden
- FCL kann "in Ruhe" angeeignet und benutzt werden
- Viele 3th Party Komponenten werden in Delphi 8 verfügbar sein (z.B. DevExpress QuantumGrid, ...)
kontra- Delphi ist natürlich nicht von Microsoft
- neue Änderungen / Erweiterungen im .net Framework werden nicht so schnell in Delphi umgesetzt wie bei MS Produkten
- VCL.NET muss teilweise mit FULL TRUST laufen. (wegen P/Invoke)
- von lokaler HDD läuft Anwendung ohne Probleme,
- von Netzlaufwerk gibt's Fehlermeldung "System.Security.Permissions.SecurityPermissio n"
- Läst sich aber lösen (mehrere Lösungen: caspol -s off oder Intranet Zone auf FULL TRUST setzen oder Assemblies mit Strong Name Schlüssel signieren und vertrauen oder ...)
- langsame IDE
neutral- Kompatibilität zu Kylix?
- Kompatibilität zu Win32
- Was unter .NET nicht funktioniert:
- Direktive absolute
- Real48 sechs Byte-Gleitkommazahlen
- File of <type> (TextFile wird aber unterstützt). File of type funktioniert nicht, weil es unterschiedliche Speicherabbilder auf unterschiedlichen Plattformen erzeugen würde, und Speicher in .NET kann sich verschieben.
- GetMem, FreeMem, ReallocMem (verwenden Sie stattdessen dynamische Arrays, New() und Dispose())
- ExitProcs
- die alte Object-Syntax (type TFoo = object)
- TVarData und Variant-Interna (aber Varianten selbst sind implementiert)
- AfterConstructor und BeforeDestructor - kein Platz für sie in der CLR. Aber keine große Sache, da sie virtuelle Aufrufe aus dem Konstruktor ausführen können.
- Sie können keine Objektreferenz in einen Integer umwandeln (z.B. mit TList), weil Sie ihn nicht zurück umwandeln können - aufgrund von Garbage Collection und verwaltetem Code können Sie diese Tricks mit Pointern und lustigen Typumwandlungen nicht tun. Außerdem gibt es keine Garantie, dass Integer und Pointer die gleichen Typen auf einer gegebenen Plattform sind.
- Assemblies die Delphi 8 spezifische Dinge verwenden, laufen nicht in anderen .net Sprachen
Es ist aber durchaus möglich Assemblys zu schreiben die in allen .net Sprachen funktionieren.
- in D8 verwendete Assemblys, die zur Laufzeit der IDE geändert werden machen Probleme. (man muss fast immer die IDE neu starten)
C#
pro
kontra- Für Delphi Entwickler eine gewisse Einarbeitungszeit, da
- keine VCL mehr
- andere Sprachsyntax
- andere IDE
- Source der FCL wird nicht mitgeliefert !!!
vb.net
pro
kontra- es ist nicht alles machbar
.net Framework
pro- Es können beliebig viele Versionen nebeneinander (gleichzeitig) installiert sein (1.0, 1.1, 2.0, ...)
- Die Anwendung sucht sich das "richtige" Framework
- Framework ist Betriebssystemunabhängig (gleiche API für alle Win32 Versionen, Linux (Mono))
kontra- auf dem Zielrechner muss das Framework installiert sein
edit: Punkte von Delphipraxis Mitgliedern aufgenommen
nieurig: Code-Kompatiplität zu Kylix?, auf dem Zielrechner das Framework installiert?
ak1: Update Delphi 8 ist billiger als Neukauf Visual Studio.NET, gewohnte Komponenten ebenfalls in Delphi 8 (VCL)
Robert_G: Assemblies die Delphi 8 spezifische Dinge verwenden, laufen nicht in anderen .net Sprachen, Es is total friemelig in D8 eine Assembly zu verwenden, die zur Laufzeit der IDE geändert wurde. (man muss fast immer die IDE neu starten