Welche Konsequenzen zieht ihr aus den Features für XE2?

[mkinzler]

Geht genauso must halt nur auf Selektion überprüfen

[cookie22]

Zitat von MEissing:

Zitat von cookie22:

Ich wette Fire Monkey gibt der Komponentenentwicklung unter Delphi wieder einen Schub und wir sehen auch viele neue Commercial und Freeware Kompos. Da gibt es sicher auch das ein oder andere gute Grid.

Ich wüsste nichts, was an dem FireMonkey Grid "schlecht" ist....

Hat ja auch niemand behauptet, irgendwer hat gesagt es ist gar keins dabei.

[mkinzler]

So entstehen Gerüchte ...

[mquadrat]

Ich schrieb "kein sinnvolles" - von gar keinem hab ich nicht geredet Ich bezog mich nur auf die Aussage im DevExpress Blog und die war ja nicht "gutes Grid is dabei, daher entwickeln wir keins", sondern "Erst mal abwarten ob das überhaupt jemand nutzt". Sorry für die Verwirrung

[Chemiker]

Hallo,

gibt es eigentlich Informationen, ob der integrierte Assembler von Delphi auch auf 64Bit angepasst wird.

Bis bald Chemiker

[jaenicke]

Ich zitiere mal was bereits vor einiger Zeit dazu veröffentlicht wurde:

Zitat von David Intersimone (auf Englisch):

• Du kannst keine Assemblerblöcke in Pascalfunktionen nutzen. Nur komplett in Assembler geschriebene Funktionen.
• Der Stack muss bei jedem Unterprogrammaufruf mit CALL an 16-Byte ausgerichtet sein.
• Die ersten vier Parameter werden jetzt in RCX, RDX, R8 und R9 übergeben, bzw. bei MMX in XMM0 bis XMM3.

Mehr siehe hier:
http://www.embarcadero.com/products/delphi/64-bit

[bernerbaer]

Ich habe auf der Seite von David Intersimione folgenden Kommentar gefunden:

Zitat:

Delphi 64-bit compiler is worse than 32-bit one. It produces inefficient and much slower code (64-bit code optimizer is scheduled for XE3, as I see over QC). It doesn’t support Extended type, only 64-bit emulation (QC #92342). So only purpose of 64-bit compiler is to add a several lines to new feature list, though it is useless?

Live Bindings feature has been met sceptically too (QC #97444).

Leider habe ich unter den angegebenen QC Nummern bei Embarcadero nichts gefunden(Either there is no report #xxxxx, or you are not authorized to see that report). Gibt es dazu evtl.noch weitere Infos?

für _mich_ ist die 64Bit Unterstützung der Hauptgrund für einen allfälligen Kauf von XE2 (Firemonkey wäre für mich höchstens ein gern genommenes Gadget, das ich evtl. mal auch einsetzen werde), wenn nun obige Aussage einen wahren Kern enthält, wäre das für mich fatal. Weshalb sollte ich dann nicht wie bis anhin FPC benutzen um 64 bit Code zu compilieren wenn ich solchen benötige?

[jaenicke]

Wenn ich mir den Assemblercode so anschaue (nicht bei XE 2, sondern früher), habe ich allgemein den Eindruck, dass etwas schlechter optimiert wird. Allerdings nicht so schlecht, dass der Code wirklich langsam würde, aber eben ein paar unnötige Instruktionen immer wieder mal, die man manuell nicht machen würde. Einfach ist das aber auch nicht das automatisiert zu optimieren.

Die Optimierung ist beim FPC allerdings noch schlechter. Zumindest bei einfachen Tests.

Aber wo wir bei Optimierung sind, da widerspricht sich derjenige selbst.

Zitat von bernerbaer:

Zitat:

It doesn’t support Extended type, only 64-bit emulation (QC #92342).

Einerseits möchte er gern optimierten Code, andererseits einen der langsamsten Datentypen überhaupt (da bisher aufwendig softwareseitig emuliert) weiter haben...

[Insider2004]

Es ist richtig, den Extended endlich aus Delphi XE2 rauszuwerfen, weil er nicht IEEE genormt ist. Ausserdem ist er nicht portabel.

[Uwe Raabe]

Zitat von Insider2004:

Es ist richtig, den Extended endlich aus Delphi XE2 rauszuwerfen, weil er nicht IEEE genormt ist. Ausserdem ist er nicht portabel.

Was allerdings zu der leicht paradoxen Situation führt, daß in 32-Bit mit höherer Präzision gerechnet werden kann, als mit 64-Bit.