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

[mkinzler]

Jein. Richtig nativ ist das aber nicht ( keine Wincontrols, kein Cocoa; sondern Vektorgrafik wie WPF)

[neo4a]

Zitat von bernerbaer:

Die Frage die sich mir stellt ist: Können Firemonkey-Anwendungen aussehen wie OSX- oder/und Windowsanwendungen?

Will man das? Wenn man sich die MS Office-Programme 2000-2010 als Beispiel nimmt, dann sieht man die Entwicklung der GUI.

Zitat von bernerbaer:

Wer zum Beispiel das wxWidgets Framework einsetzen kann erzielt nahezu native Anwendungen auf allen Plattformen.

Es gibt sogar eine Umsetzung für Delphi (TwinForms), die aber wohl nicht mehr weiter entwickelt wird. Alle wxWidgets-Screenshots auf der Seite sehen für meinen Geschmack etwas ...alt(?) aus.

Die UX der Gegenwart ist aus meiner Sicht mehr und mehr geprägt von Animationen und gleitenden Übergängen sowie grafisch hochwertigen GUI. Nimm Webseiten, TV-Programm, Bundesliga-Tabellen, Smartphone-GUI, iPad: Dort dreht und glämmert es, dass ich mit einer reinrassigen WinControl-App schon scheintot aussehe.

[FredlFesl]

Zitat von Bernhard Geyer:

Welche Einsatzbereiche gibt es bie denne Extended gut genug ist aber Double nicht?

Iterationen, Nullstellenberechnungen, Differenzialrechnung. So'n Zeugs.

Es 'geht' mit Double, aber bei Extended hat man weniger Frust, die Berechnungen zu optimieren.

Ich würde es manchmal (ok: selten) vermissen.

[mkinzler]

Zitat:

Iterationen, Nullstellenberechnungen, Differenzialrechnung. So'n Zeugs.

Wenn es um Genauigkeit geht, sind hier aber andere Lösungen jenseits von Fliesskommazahlen gefragt.

[himitsu]

Wobei die FPU doch wohl dennoch mit Extended rechnen wird, auch wenn sie nur mit Single/Double/Currency befüllt und ausgelesen wird.

Mit Assembler kann man so auch komplexere Berechnungen durchführen, auch ohne Extended, solange man die Zwischenwerte nicht aus der FPU rausholt.
Wobei notfalls in Assembler eh Extended verfügbar wäre, selbst wenn es Delphi nicht mehr unterstützen solte.

Zitat von mkinzler:

Wenn es um Genauigkeit geht, sind hier aber andere Lösungen jenseits von Fliesskommazahlen gefragt.

Solange man nicht eine höhere Geschwindigkeit benötigt.
MathLibs sind ja nicht die Schnellsten. (viele CPU/FPU-Befehle gegen einen FPU-Befehl)

[mkinzler]

Zitat:

Wobei die FPU doch wohl dennoch mit Extended rechnen wird, auch wenn sie nur mit Single/Double/Currency befüllt und ausgelesen wird.

Unter 64Bit gibt es keine FPU, sondern nur SSE/AVX.

[himitsu]

OK und mit welcher Auflösung (Bits) kann man da rechnen?

Mit den vollen 128 Bit wird man da wohl nicht einzelne Fließkommadinge berechnen können

[Bernhard Geyer]

Zitat von FredlFesl:

Zitat von Bernhard Geyer:

Welche Einsatzbereiche gibt es bie denne Extended gut genug ist aber Double nicht?

Iterationen, Nullstellenberechnungen, Differenzialrechnung. So'n Zeugs.

Und wie oft wird in diesem Bereich Delphi für das Number-Crunsching verwendet? Wenn dann wohl eher eine Delphi-GUI die eine C/C++-Dll aufruft.

[mkinzler]

Zitat von himitsu:

OK und mit welcher Auflösung (Bits) kann man da rechnen?

Mit den vollen 128 Bit wird man da wohl nicht einzelne Fließkommadinge berechnen können

SSE unterstützt m.W. nur double precision, dass wird der Grund für das Nichtvorhandensein des extended-Typen unter 64Bit sein ( obwohl der Typ ja existiert nur halt kein Unterschied zum double besteht)

[Bernhard Geyer]

Von LMD gibt es einen Blog-Eintrag bezüglich XE2 und Firemonkey-Support