Delphi XE6 im Anmarsch

[Union]

Zitat von Insider2004:

Übrigens war die D5 RTL in Obj-Assembler geschrieben! Das ging ab, wie Rakete! In D6 hat Borland dann alles in .pas verpackt und wurde damit so langsam wie wir es heute kennen.

Keine Sorge, aufgrund massiven Einsatzes von (schlecht geschriebenen) Class-Helpern und RTTI wird das auch immer langsamer.

[TRomano]

Auch ich bin ein großer freund von kurzen, effektiven und schnellen Tools und verwende den Assembler, wo es Sinn macht. Leider ist irgendwann die Unterstützung der neueren Befehlssätze (AVX,AVX2) "abgebrochen" worden, oder es dauerte bis sie im Inline-Assembler unterstützt wurden. Für meine Array-Libraries habe ich dann HLA benutzt und die Obj-RFiles eingebunden. Das hatte den Vorteil, dass ich mir sogar den übersetzenden Assembler aussuchen konnte ... Das in der RTL immer was rauszuholen ist bewies das FastCode-Projekt .

Natürlich hat Emba das Problem, dass man bei den ganzen Plattformen, die man unterstützt (und dazu noch 32/64Bit), die RTL unheimlich mit Sourcecode aufblasen würde. geht also nur dser Weg über einen gut optimierenden Compiler ... da sehe ich allerdings nicht so viel Licht am Ende des Tunnels. Parallelisierung, OpenCL und andere Kandidaten harren da auf ihre Aufnahme.

Aber in der nächsten version wird bestimmt alles besser !!!

P.S.: ich arbeite nun mittlerweile seit der Version 1 mit Delphi, hatte als Student TurboPascal am Wickel (aber auch Fortran) und habe bisher immer gerne mit Delphi gearbeitet. Es wird auch so bleiben ...

[hanspeter]

Zitat von Union:

Zitat von Insider2004:

Übrigens war die D5 RTL in Obj-Assembler geschrieben! Das ging ab, wie Rakete! In D6 hat Borland dann alles in .pas verpackt und wurde damit so langsam wie wir es heute kennen.

Keine Sorge, aufgrund massiven Einsatzes von (schlecht geschriebenen) Class-Helpern und RTTI wird das auch immer langsamer.

Ich weis nicht wie sich die Nutzerzahlen Delphi klassisch (Altlasten) und Delphi mobile verteilen.
Ich habe aber die Befürchtung das sich die massiven Änderungen in der RTL negativ auf die VCL basierte Entwicklung auswirken und hier den Code immer weiter aufblähen.
Smart linken scheint auch nicht mehr aktuell zu sein.
Schaltet man zum Beispiel benutzerdefiniert Stile ein, dann wird eine Handvoll Unit zusätzlich eingebunden.
Bei mir blähen diese den Quellcode um mehr als 20 mB auf.
Schaltet man dann die Style wieder ab (Windows) dann ändert sich die Größe erst wieder, wenn man alle Units händisch entfernt.

Gruß Peter

[jaenicke]

Zitat von hanspeter:

Smart linken scheint auch nicht mehr aktuell zu sein.
Schaltet man zum Beispiel benutzerdefiniert Stile ein, dann wird eine Handvoll Unit zusätzlich eingebunden.
Bei mir blähen diese den Quellcode um mehr als 20 mB auf.
Schaltet man dann die Style wieder ab (Windows) dann ändert sich die Größe erst wieder, wenn man alle Units händisch entfernt.

Das war noch nie anders. Wenn eine Unit initialization Abschnitte oder ähnliches hat, reicht schon das reine Einbinden der Unit, damit der Quelltext wächst.
Der Linker kann nur Sachen auslassen, die er als nirgends verwendet erkennen kann.

[himitsu]

Und Resourcen in eingebundenen Dateien kann der Linker sowieso nicht entfernen, da er nicht weiß, ob die Resourcen verwendet werden oder nicht.

Der Linker kann nur Funktionen/Klassen weglassen, wenn er erkennt, daß die nirgendwo verwendet werden.
Aber Dank der neuen RTTI und der Möglichkeit Klassen/Mehoden dynamisch aufzurufen, wird nun standardmäßig einfach alles eingebunden, egal ob genutzt oder nicht. (außer man deaktiviert es)
Früher betraf das nur published Methoden/Property/Felder, aber jetzt auch Public, Protected und sogar Private, welche man via RTTI standardmäßig erreichen kann.

[Daniel]

Zitat von himitsu:

[...]aber jetzt auch Public, Protected und sogar Private, welche man via RTTI standardmäßig erreichen kann.

Aber natürlich. Sonst macht doch das gesamte System keinen Sinn. Delphi nimmt hierbei keine Sonderstellung ein, das ist ja bei C# und Java nicht anders.

[himitsu]

Man hättes es natürlich auch andersrum implementieren können, so wie beim {$M+} aka {$TYPEINFO ON} , wo man das nur für die Klassen aktiviert, bei denen es auch benötigt wird.

Und wozu macht das PRIVATE dann noch Sinn, wenn es standardmäßig urplötzlich wieder Public ist? (wobei man das nun wenigstens dazu nutzen kann, um sich z.B. in grausam programmierte VCL-Klassen zu hacken )


Also, mich stört nicht, dass sowas überhaupt geht, aber so einige der Standardvorgaben sind echt grauenvoll.

[Daniel]

Zitat von himitsu:

Und wozu macht das PRIVATE dann noch Sinn, wenn es standardmäßig urplötzlich wieder Public ist?

Da vermischst Du aber mehrere Ebenen. "Private" ist und bleibt privat im Sinne der Objekt-Orientierung bzw. im Sinne der Vererbungshierarchie. Du hast jetzt mit der RTTI die Möglichkeit, ein stets mächtiger werdendes Werkzeug anzusetzen, um die Klassen auseinander zu nehmen. Mit "Gewalt" ist man von außen schon immer an private Felder heran gekommen, der Weg ist nur leichter geworden.

[greenmile]

Geht das nicht langsam am Thema vorbei?

[Daniel]

Tut es. Klar.
Warten wir einfach bis kommende Woche, dann haben wir vermutlich mehr zum Thema XE6.