Delphi.NET Plattformunabhängig?

[Robert_G]

Zitat von jbg:

Zitat von Robert_G:

Das kann vielleicht an der 2. RTTI liegen

Welche 2. RTTI?

RTL
Jede Delphi.Net Assembly braucht die Borland.Delphi.System.dll -> Warum kapiere ich beim besten Willen nicht.
Nunja... wenn ich etwas im VS programmiere ,zum Bleistift um eben keine Borland Assemblies benutzen zu müssen*, finde ich es einfach nicht akzeptabel, dass es mir TMS oder die Indys aufzwingen wollen.
Also verzichte ich einfach auf jeden, der es macht


*nicht weil ich nichts dazupacken will, eher weil ich diese Assembly nicht dazupacken will

[jbg]

Zitat von Robert_G:

Jede Delphi.Net Assembly braucht die Borland.Delphi.System.dll -> Warum kapiere ich beim besten Willen nicht.

Das ist eigentlich ganz einfach. Jedes Delphi-Programm unterstützt die "initialization" (kein Problem mit Klassenkonstruktoren) und "finalization" Abschnitte. Letzterer ist wegen eines fehlenden Klassendestruktors (ist ja auch was unsinniges aus .NET Sicht) nur mit Hilfsmitteln möglich und der Code steckt schon mal in der Borland.Delphi.System unit. Dann kommen die ganzen dinge wie dynamische Arrays, class helpers, virtuelle Konstruktoren.
Im Großen und Ganzen steckt da eben wie bei nativen Code der Kern der RTL drinnen. Das das bei C# nicht notwendig ist, ist klar. Das ist wie bei C++ mit der msvcrtXX.dll, die auch auf jedem Rechner vorhanden ist und somit nicht mit ausgeliefert werden muss. So ist die C# Runtime in der System.dll integriert (besser ausgedrückt: die C# RTL ist die System.dll).

Die Alternative zur Borland.Delphi.System wäre, dass der Compiler in jedes Assembly deren Code injiziert und den Unit-Klassennamen mit einer unique ID vergibt, damit es nicht zu Namenskonflikten kommt. Aber dafür hat sich Borland nicht entschieden. Die nutzen lieber ein gemeinsames Assembly, wie es sich unter .NET gehört.

Der Grund warum jedes Delphi-Programm die System Unit benötigt und ein C/C++ Programm ohne alles auskommt, liegt darin, dass man in Pascal immer einen gewissen Funktionsumfang hat, wohingegen in C/C++ alles über extrene Bibliotheken statisch/dynamisch hinzugelinkt wird. Beides hat seine Vor- und Nachteile. Das eine ist leicht austauschbar, das andere verhält sich immer gleich. (Aber damit gehe ich jetzt glaube ich zu weit weg vom Thema)

[Robert_G]

Zitat:

So ist die C# Runtime in der System.dll integriert (besser ausgedrückt: die C# RTL ist die System.dll).

Genau das ist eben nicht der Fall! C# ist absolut CLS compliant. Die einzige RTL, die es benötigt ist die CLR (noch nichtmal zwingend die MsCoreLib.dll )

Auch wenn es wieder wie eine Rumzickerei klingt: Objektiv betrachtet wirken allen Argumente, die du aufgeführt hast, wie Ausreden für eine .Net-Sprache, die eigentlich keine ist.
Statische Konstruktoren sind nunmal das Mittel in .Net. Wenn Borland auf initialisierung und finalization besteht (Warum auch immer...), dann sollten sie es mit .Net Bordmitteln lösen oder einfach sein lassen.
Virtuelle Konstruktoren rechtfertigen ebenfalls keine 2. RTL. Wenn man diese Funktionalität will kann man sich ganz einfach eine virtual protected Methode anlegen, die man im Konstruktor aufruft. Dadurch würde es in jeder .Net Sprache funktionieren.

Aber egal... Ich produziere mal wieder nur hypothetisches Gesülze. Es ist nunmal so wie es ist: Mancheiner greift aufgrund dieser "features" zu D.Net und ich werde seine Kompilate nicht anfassen.