Delphi XE6 im Anmarsch

[mquadrat]

Zitat:

Zitat von Insider2004 (Beitrag 1255053)

Das wird EMB tunlichst vermeiden. Die werden doch nicht wieder ein Monster-Qualitäts-Produkt (MQP) wie Delphi 7 rauszubringen, welches so gut ist, dass es heute noch verwendet wird.

Übrigens ist es sehr erstaunlich, wie wenig zwischen XE2 und XE5 passiert ist. Da wurden 3 Versionen verbraten für ein paar Miniänderungen.

Heute noch D7 zu benutzen ist IMHO eher kein Qualitätsmerkmal, sondern festigt eher den Ruf Delphis "innovationsresistent" zu sein.

[greenmile]

Naja um ehrlich zu sein gibt es kaum etwas was ich mit Delphi 5 nicht entwickeln kann.
Dank TMS, VCLSkin und wie sie alle heißen kann ich viele kleine Tools damit problemlos entwickeln.

Natürlich ist XE schicker ...

[Uwe Raabe]

Zitat:

Zitat von greenmile (Beitrag 1255065)

Naja um ehrlich zu sein gibt es kaum etwas was ich mit Delphi 5 nicht entwickeln kann.

Das habe ich für Assembler auch schon mal gehört...

[greenmile]

Nicht alles was XE neues mitbringt, ist besser oder stabiler ...

[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.

[greenmile]

Ahhh ... das erklärt doch einiges.

[arnof]

Zitat:

Zitat von greenmile (Beitrag 1255065)

Naja um ehrlich zu sein gibt es kaum etwas was ich mit Delphi 5 nicht entwickeln kann.
Dank TMS, VCLSkin und wie sie alle heißen kann ich viele kleine Tools damit problemlos entwickeln.

Natürlich ist XE schicker ...

Es ist nicht lange her da dachte ich das auch noch, aber das ist mittlerweile nicht mehr so. D5 war bis vor 5 Monaten meine VCL-Hauptumgebung, jetzt schüttelt es mich wenn ich da was machen muss.

[Bernhard Geyer]

Zitat:

Zitat von Insider2004 (Beitrag 1255078)

Ü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.

Komisch nur das in meinen Delphi 6 einiges in der RTL noch in Assembler läuft. Hast du hier ein anderes Delphi 6?
Du hast aber sicherlich aus Performancevergleiche zwischen D5 und D6. Ich jedenfalls keine mindestens einen Bereich in der neue Delphi-Versionen (ab D2009) gegenüber D6 wie ein Panther gegenüber einer Schnecke ist (Panther = Delphi XE+)

Was sie umgebaut haben ist der ganze Variant-Typ. Der wurde von Native auf Pascal umgestellt um mit der CLX plattformunabhängig zu werden.
Dieser Umbau wäre auch mit FMX nötig gewesen.

[jaenicke]

Zitat:

Zitat von greenmile (Beitrag 1255079)

Ahhh ... das erklärt doch einiges.

Wenn es stimmen würde, ja... tut es aber nicht. Klar gab es da Assemblerteile, aber die gab es auch danach noch. Der größte Teil ist auch in Delphi 5 Pascal Code wie ein Blick in die Quelltexte auch sofort zeigt.

[himitsu]

Selbst aktuelle XEs haben noch Assembler drin, mit einer alternativen Pascalcode, wenn die Zielplattform das nicht unterstürtzt.

Also dann so um 2006 der FastMM und Teile des FastCode-Projekts aufgenommen wurden, ging es dann auch nochmal ein Stück flotter.
In der VCL wurden selbst Memos/Richedits gefühlt etwas schneller und mehr konnten die auch, nachdem dort aktuellere Versionen eingebunden wurden.

[Union]

Zitat:

Zitat von Insider2004 (Beitrag 1255078)

Ü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:

Zitat von Union (Beitrag 1255091)

Zitat:

Zitat von Insider2004 (Beitrag 1255078)

Ü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:

Zitat von hanspeter (Beitrag 1255165)

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. :wall:

[Daniel]

Zitat:

Zitat von himitsu (Beitrag 1255179)

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

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

Delphi-Quellcode:

{$M+}

aka

Delphi-Quellcode:

{$TYPEINFO ON}

, wo man das nur für die Klassen aktiviert, bei denen es auch benötigt wird. :stupid:

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 :angel:)


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

[Daniel]

Zitat:

Zitat von himitsu (Beitrag 1255196)

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.

[Stevie]

Zitat:

Zitat von himitsu (Beitrag 1255179)

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. :wall:

Nicht ganz richtig, die Standardsichtbarkeit für Method RTTI ist public und published. Für private und protected Methoden bekommt man in aller Regel einen Compiler Hinweis, wenn diese nirgendwo benutzt werden. Also können sie in aller Regel auch nicht rausgelinked werden, weil man sie höchstwahrscheinlich irgendwo aufruft. Nur nicht benutzte nicht virtuelle public Methoden werden durch RTTI nicht rausgelinkt, da man sie ja über RTTI aufrufen kann.

Und auch das kann man ausschalten, wenn es einen stört, indem man die WEAKLINKRTTI Directive benutzt.

[mquadrat]

Zitat:

Zitat von himitsu (Beitrag 1255196)

Man hättes es natürlich auch andersrum implementieren können, so wie beim

Delphi-Quellcode:

{$M+}

aka

Delphi-Quellcode:

{$TYPEINFO ON}

, wo man das nur


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

Ohne die RTTI ist vieles schwieriger. Data-Binding, ORM, ... Sprich alles, bei dem man Informationen über eine Klasse braucht. Man kann jetzt natürlich darüber streiten, ob ein ORM Zugriff auf private Eigenschaften / Methoden haben muss, aber der Default sollte sein "Geht immer". Ein Default "Geht, wenn man kryptischen Schlüssel, den keiner kennt einbaut" dürfte schnell in einen Support-Horror münden..

Anders formuliert: Defaults sollten immer das Max abdecken, nie das min. Zumindest meine Meinung.

Hoffentlich ist bald der 16. damit wir dann auch wirklich über XE6 diskutieren können :D

[Insider2004]

Erste Erfahrungsberichte?

[mquadrat]

Zitat:

Zitat von Insider2004 (Beitrag 1255819)

Erste Erfahrungsberichte?

Ohne die Komponenten kann ich noch wenig sagen. Gefühlt ist es schneller, sobald es mal gestartet ist. Aber die richtig großen Projekte kann ich aufgrund der noch fehlenden Komponenten nicht testen.

Wobei ich eigentlich auch einfach die alten Komponenten installieren könnte. Soviel hat sich ja im Windows / VCL Bereich nicht verändert.

[pustekuchen]

Fängt ja schon gut an, bei der Installation erkennt TREND Micro Antivirus die LicenseManager.exe als "Mal_Xed-21" Virus/Malware =\

Als Workaround die exe als Ausnahmen hinzufügen, bis es ein Udpate gibt. Handelt sich um ein false-positiv, das Problem gab es schon bei XE3.

[bernau]

Zitat:

Zitat von pustekuchen (Beitrag 1255930)

Fängt ja schon gut an, ....

Das ist aber nicht ein Fehler von Emba.

[Union]

Das pssiert bei jedem Scanner und bei einigen Dateien mit schöner Regelmäßigkeit. Nach ein paar Tagen Virusupdates geht dann plötzlich alles wieder. Inzwischen scheint es ja mehr Viren zu geben als "normale" Programme, so dass auch die eindeutige Erkennung problematisch ist. Mir ist aber ein "false positive" ab und an lieber, als wenn ich mir was einfangen würde.

[Sherlock]

Zitat:

Zitat von bernau (Beitrag 1255949)

Zitat:

Zitat von pustekuchen (Beitrag 1255930)

Fängt ja schon gut an, ....

Das ist aber nicht ein Fehler von Emba.

Man könnte sich die Zeit nehmen, mal gegen eine handvoll der gängigsten Virenscanner zu laufen, und entsprechende Probleme dort zu melden. Könnte man, wenn man Geld für sein Produkt nehmen würde. Muss man aber nicht, man kann es auch den Endanwender machen lassen... hmm, ich merke ich bin übellaunig.:oops:

Halte mich jetzt lieber zurück. Bald ist Ostern und heute ist sowas wie Freitag!!

Sherlock

[MEissing]

Wir testen mit den gängigen Virenscannern..... und stehen auch mit deren Herstellern in Kontakt.

Das diese nicht unbedingt in absehbar endlicher Zeit reagieren, zeigt mir persönlich nur, wie sinnvoll ein Virenscanner ist.
(80% der Probleme, die hier auflaufen in Bezug auf Installation/Aktivierung/Betrieb, sind auf schadhafte Betriebssysteme zurückzuführen. Nein... nicht durch Viren dysfunktional geworden, sondern durch "Sicherheitssoftware".)

[Darlo]

Zitat:

Zitat von MEissing (Beitrag 1255986)

Wir testen mit den gängigen Virenscannern..... und stehen auch mit deren Herstellern in Kontakt.

Das diese nicht unbedingt in absehbar endlicher Zeit reagieren, zeigt mir persönlich nur, wie sinnvoll ein Virenscanner ist.
(80% der Probleme, die hier auflaufen in Bezug auf Installation/Aktivierung/Betrieb, sind auf schadhafte Betriebssysteme zurückzuführen. Nein... nicht durch Viren dysfunktional geworden, sondern durch "Sicherheitssoftware".)

Sieht bei uns ähnlich aus und die ganzen False-Positive nerven gewaltig.... Unter Windows 8 finden die meisten User nicht den Knopf der die Anwendung trotzdem ausführt, ist glaube ich unter "weitere Informationen" versteckt...

[jaenicke]

Zitat:

Zitat von MEissing (Beitrag 1255986)

Nein... nicht durch Viren dysfunktional geworden, sondern durch "Sicherheitssoftware".

Bei uns ist ein großes Problem auch diverse Tuningsoftware (bei uns liebevoll Systemzerstörungssoftware genannt).

[Sherlock]

Zitat:

Zitat von MEissing (Beitrag 1255986)

Wir testen mit den gängigen Virenscannern..... und stehen auch mit deren Herstellern in Kontakt.

Das diese nicht unbedingt in absehbar endlicher Zeit reagieren, zeigt mir persönlich nur, wie sinnvoll ein Virenscanner ist.
(80% der Probleme, die hier auflaufen in Bezug auf Installation/Aktivierung/Betrieb, sind auf schadhafte Betriebssysteme zurückzuführen. Nein... nicht durch Viren dysfunktional geworden, sondern durch "Sicherheitssoftware".)

Ich nehme alles zurück, bitte in aller Form um Entschuldigung und schließe mich dem allgemeinen Tenor an, daß Virenscanner - aus Entwicklersicht - böse sind. :)

Sherlock

[bernau]

Zitat:

Zitat von Sherlock (Beitrag 1256008)

Ich nehme alles zurück, bitte in aller Form um Entschuldigung und schließe mich dem allgemeinen Tenor an, daß Virenscanner - aus Entwicklersicht - böse sind. :)

Das mit dem Überlaunig aus deinem vorherigen Post scheint zu stimmen ;-) (Nicht böse gemeint)

[Sherlock]

Kam das eben nicht ernst rüber? ...war aber so gemeint.

Sherlock

[himitsu]

Cool, wir haben gleich weltweit 100 Leute, welche sich auch die Trial-DVD runterdeladen haben

Macht mir irgendwie Sorgen.



Nur bissl blöd, daß es bei den Online-Installern und den Downloads der Lizenz-Käufer keine Downloadzahlen gibt.

[Darlo]

Laßt uns doch froh sein, dass es XE6 gibt und dass es weiter entwickelt wird!

[Darlo]

doppelt...

[himitsu]

Da fühlt man sich schon fast bissl elitär. :mrgreen:

http://cc.embarcadero.com/PopularDownloads.aspx
Unter die Top 20 schaffte es selbst die BDE, das coole Wallpaper und Turbo Pascal.

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1256069)

http://cc.embarcadero.com/PopularDownloads.aspx
Unter die Top 20 schaffte es selbst die BDE, das coole Wallpaper und Turbo Pascal.

Wenn man sich aber die Daten in Updated ansieht, sticht RAD Studio 2007 deutlich hervor. Beschränkt man wiederum den Zeitraum auf letztes Jahr, steht "Delphi XE5 and C++Builder XE5 ISO (Includes Update 2)" an der Spitze.

Wie war das noch mit "Trau keiner Statistik...'?

[himitsu]

Zitat:

Zitat von Uwe Raabe (Beitrag 1256074)

Beschränkt man wiederum den Zeitraum auf letztes Jahr, steht "Delphi XE5 and C++Builder XE5 ISO (Includes Update 2)" an der Spitze.

Interessant ist auch, daß sich grade erst wieder jemand ein Turbo Pascal 5.5 besorgt hat. :lol: