Vor und Nachteile von Delphi 8 for .net vs c#, vb.net

[MaBuSE]

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

[MathiasSimmack]

Zitat von MaBuSE:

neue Änderungen / Erweiterungen im .net Framework werden nicht so schnell in Delphi umgesetzt wie bei MS Produkten

Ist das nicht ein Irrtum? Wenn es neue Eigenschaften oder Erweiterungen im .NET-Framework gibt, dann kannst du die auch unter Delphi benutzen, weil Delphi ja in der Hinsicht komplett auf das Framework zugreift. Es mag IMHO sein, dass die VCL.NET dann nicht auf bestimmte Sachen zugreifen kann. Aber reine WinForms-Anwendungen sollten keine Probleme verursachen.

Zumindest habe ich das aus dem Probekapitel von Andreas Kosch so herausgelesen. Das war IMHO ein Satz wie:

Zitat:

Nie wieder auf Header-Übersetzungen warten

o.ä.


Die einzige Befürchtung, die ich hege, ist das Microsoft wieder dieses Runtime-Chaos wie bei VB einführt. Oder in dem Fall: du hast parallele Versionen vom .NET-Framework 1.1 und 2.0 (irgendwann im nächsten Jahr), und Delphi funktioniert natürlich nur mit der 1.1er-Version. Um v2 verwenden zu können, wird (natürlich!) ein Update auf Delphi 10 notwendig.
Aber (und deswegen mal kein Seitenhieb in Richtung Borland) davon wären dann Visual Studio-Entwickler wohl auch betroffen.

[MaBuSE]

Zitat von MathiasSimmack:

Zitat von MaBuSE:

neue Änderungen / Erweiterungen im .net Framework werden nicht so schnell in Delphi umgesetzt wie bei MS Produkten

Ist das nicht ein Irrtum?

Ich glaube nicht.
In der .net preview zu D7 war ja auch eine Änderung am Framework (v1.0 auf v1.1)
Meines Wissens musste die komplette VCL neu kompiliert werden.

Visual Studio fragte den Entwickler nur:
"Für welche Frameworkversion wollen Sie entwickeln?"
zur Auswahl stand dann 1.0 und 1.1

Wenn die VCL auf 1.1 aufsetzt und dann 2.0 kommt und man die VCL neu kompiliert:
Wie erzeuge ich dann eine Anwendung für Framework 1.1 ?

Es ist ja wohl nicht praktikabel jedesmal die ganze VCL (und alles was davon abhängt) neu zu kompilieren.

Zitat von MathiasSimmack:

Die einzige Befürchtung, die ich hege, ist das Microsoft wieder dieses Runtime-Chaos wie bei VB einführt. Oder in dem Fall: du hast parallele Versionen vom .NET-Framework 1.1 und 2.0 (irgendwann im nächsten Jahr), und Delphi funktioniert natürlich nur mit der 1.1er-Version. Um v2 verwenden zu können, wird (natürlich!) ein Update auf Delphi 10 notwendig.
Aber (und deswegen mal kein Seitenhieb in Richtung Borland) davon wären dann Visual Studio-Entwickler wohl auch betroffen.

Eben nicht. bei Visual Studio kann man die Zielplatform auswählen

Einer der Vorteile vom .net Framework ist ja, dass sie beliebig viele Versionen nebeneinander installieren lassen. Die Anwendung weiss ja in welchem Framework sie laufen kann.

http://www.delphi-source.de/grundlagen/dotnet/unterschiede.php

Wenn Delphi für .NET ein Package sieht, importiert es die Symbole aus Metadaten und schreibt sie dann in nativem Delphi-Format auf Platte. Der Compiler kann sie nun etwa tausendmal schneller laden, als wenn er sie aus den Metadaten importiert.

Diese Daten müssten ja dann auch auf das "neue" Framework geändert werden

[MathiasSimmack]

Zitat von MaBuSE:

Zitat von MathiasSimmack:

Ist das nicht ein Irrtum?

Ich glaube nicht.
In der .net preview zu D7 war ja auch eine Änderung am Framework (v1.0 auf v1.1)
Meines Wissens musste die komplette VCL neu kompiliert werden.

Ja, und?

Ich schrieb

Wenn es neue Eigenschaften oder Erweiterungen im .NET-Framework gibt, dann kannst du die auch unter Delphi benutzen, weil Delphi ja in der Hinsicht komplett auf das Framework zugreift. Es mag IMHO sein, dass die VCL.NET dann nicht auf bestimmte Sachen zugreifen kann. Aber reine WinForms-Anwendungen sollten keine Probleme verursachen.

Ich habe doch gesagt: Bei der VCL wäre es möglich, dass es Probleme geben kann. Aber ich arbeite nicht mit der VCL.NET. Wenn du mich schon zitierst, dann lass solche Dinge nicht weg. Es verfälscht meine Aussage irgendwie.

[MaBuSE]

Zitat von MathiasSimmack:

Wenn du mich schon zitierst, dann lass solche Dinge nicht weg. Es verfälscht meine Aussage irgendwie.

Normalerweise zitiere ich nie alles. Das kann man ja ein paar Zeien weiter oben nachlesen.
Und sorry, ich wollte Dich (und Deine Aussagen) nicht verfälschen.

[MaBuSE]

Zitat von MathiasSimmack:

Ja, und?

Wir sind am prüfen, ob Delphi 8 bei uns im Haus eingesetzt wird
oder ob wir nach C# wechseln.

Die VCL.NET ist für uns schon wichtig!
Das ist einer der wichtigen Gründe die für Delphi 8 sprechen.

Wenn wir mit der VCL nicht vernünftig arbeiten können
(also eh alle neu programmieren müssen), spricht nicht mehr viel für Delphi.
Dann würde die Tendenz nach C# gehen.

Ich schrieb

Wenn die VCL auf 1.1 aufsetzt und dann 2.0 kommt und man die VCL neu kompiliert:
Wie erzeuge ich dann eine Anwendung für Framework 1.1 ?

Es ist ja wohl nicht praktikabel jedes Mal die ganze VCL (und alles was davon abhängt) neu zu kompilieren

Na ja, in zweieinhalb Wochen kommen zwei Borland Mitarbeiter zu uns ins Haus, die werd ich dann mal fragen.


Für Änderungen oder Verfälschungen an MathiasSimmack wird keinerlei Haftung übernommen

[nieurig]

Hallo Mabuse,
ich nehme an, dass die Entscheidung für .NET bereits getroffen ist und es nur noch um die Frage der Sprache geht.

Sonst habe ich noch ein Contra. Die Lauffähigkeit des Programmes hängt davon ab, das auf dem Zielrechner das Framework installiert ist - unde wenn nicht ?

Ach ja, wie steht es eigentlich um die Code-Kompatiplität zu Kylix? Ist das dann überhaupt noch möglich?

Viel Erfolg beim Sammeln. Ich werde Deine Liste aufmerksam beobachten, weil mich diese Uberlegungen auch schon länger umtreiben.

Niels

[MaBuSE]

Zitat von nieurig:

ich nehme an, dass die Entscheidung für .NET bereits getroffen ist und es nur noch um die Frage der Sprache geht.

Genau

Danke für Deinen Beitrag, habe Punkte in Liste aufgenommen (s.o.)

[ak1]

Pro Delphi 8:

-ein Update auf Delphi 8 ist wehsentlich billiger als ein Neukeuf von visual Studio.NET
-die Datenbankkomponenten sind in Delphi 8 besser
-gewohnte Komponenten wie Rave können ebenfalls in Delphi 8 verwendet werden

[Robert_G]

D8

• Pro ...
  • Bis auf die buntere Komponentenpalette ( ), buggy ECO und den für mich sinnloses BDP.Net fällt mir nichts ein.
  • Wenn man D8 mit #develop vergleicht, punktet es mit seinem ASP.Net designer (den wird #develop wohl so schnell nicht kriegen)
• Kontra:
  • Die wahrscheinlich instabilste und lahmste IDE seit es IDEs gibt.
  • Assemblies in D8 zu schreiben ist kompletter Schwachfug!
    Eine Version der dll, die mit D8 funktioniert, wird mit KEINER anderen .Net Sprache laufen, und andersherum (läuft sie mit z.B. C# wird sie NICHT mit D8 laufen). (RTTI)
  • 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 )

Meiner Meinung nach taugt D8 nur etwas um sich GUIs und ASP.Forms zusammenzuklicken. Der wirklich aufwqendige Code ist IMHO in einer in #develop geschriebenen Assembly viiieeel besser aufgehoben. Damit kann er wenigstens ohne 1-3 cholerische Anfälle in einer anderen Sprache weiter verwendet werden. Außerdem muss man in D8 ständig den kompletten Pfad zu einer Klasse tippen. (Ihr kennt sicher System.Windows.Forms.DialogResult.OK )