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

[mschaefer]

...zumindest was die nativen Datentypen angeht. Ansonsten hat man die Möglichkeit BCD-Unterstützung zu verwenden.

[himitsu]

Meistens reichen doch Single und Double auch so noch aus?

Wobei Double sich doch auch noch praktisch einfügt:
- Double = 8 Byte
- Speicherausrichtung = 8 Byte

[Insider2004]

Zitat von 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.

Blöd wird es nur, wenn es Aufgrund von Rundungseigenschaften erzeugte Daten von 32-bit-Programmen abweichen gegenüber denen von 64-bit-Programmen. Da hilft nur Extended zu meiden.

[Bernhard Geyer]

Zitat von Insider2004:

Blöd wird es nur, wenn es Aufgrund von Rundungseigenschaften erzeugte Daten von 32-bit-Programmen abweichen gegenüber denen von 64-bit-Programmen. Da hilft nur Extended zu meiden.

Welche Einsatzbereiche gibt es bie denne Extended gut genug ist aber Double nicht?
Seit dem Versuch von Delphi.NET (Nicht Prism) sollte es klar sein das Extended verschwindet.

[himitsu]

Im Notfall gibt es ja immernoch gewisse MatheLibs, welche man nutzen könnte, sollte wirklich mal mehr von Nöten sein.

[Uwe Raabe]

Zitat von Insider2004:

Blöd wird es nur, wenn es Aufgrund von Rundungseigenschaften erzeugte Daten von 32-bit-Programmen abweichen gegenüber denen von 64-bit-Programmen. Da hilft nur Extended zu meiden.

Das mit dem Meiden ist halt nicht immer so einfach, wenn man einen Haufen von uraltem in Turbo-Pascal entwickeltem Code hat, bei dem einige Konstanten empirisch auf die Genauigkeiten von Extended angepasst sind. Damals waren Koprozessoren verdammt teuer und wurden natürlich auch bis an die Grenzen ausgenutzt. Natürlich kann man das alles auch mit Double machen, aber das ist halt ein ziemlicher Aufwand. Ich weiß allerdings auch, daß der wohl nicht mehr zu vermeiden ist.

[Uwe Raabe]

[QUOTE=Bernhard Geyer;1119995]

Zitat von Insider2004:

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

Z.B. Verschneidungen von Körpern, die über mathematische Formeln beschrieben werden - da kann die Rechengenauigkeit gar nicht hoch genug sein. Die Effekte mangelnder Genauigkeit kennt jeder, der in einem 3D-Spiel schon mal in einer Wand stand. Der Clou bei Extended war, daß man mit einer popeligen PC-Anwendung ohne großen Aufwand genauere Berechnungen anstellen konnte, als es Millionen-(DM)-teure CAD-Programme hinbekamen.

[bernerbaer]

OK, das mit dem fehlenden extended type kann man scheinbar umgehen. Bleibt nur noch die Frage zur Leistungsfähigkeit des 64Bit Compilers, anscheinend sind da ja noch keine Optimierungen eingebaut.

Was mich auch noch beschäftigt ist Firemonkey. Alles was ich bis anhin dazu gesehen habe, sind Beispiele die mit realem Einsatz wohl kaum was zu tun haben, fliegende Bilder und rotierende 3D Texte sind wohl kaum das, was ein durchschnittlicher Programmierer im Alltag brauchen wird. Wieso sieht man nicht mal ein Beispiel mit einer Standardapplikation mit Menü, Eingabefeldern usw und zeigt das Resultat unter Windows und OSX?

Irgendwie kann ich mir noch nicht so recht vorstellen, dass mit einem "selbsgestrickten" Framework ein GUI erreicht wird, das den Anwendern ein standardmässiges, bzw gewohntes Bild übermittelt wird, (meine) Anwender reagieren oft sehr irritiert auf kleinste Abweichungen vom OS-Standard. Ist das Zielpublikum von Firemonkey etwa "nur" der APP-Entwickler, und will es nur "hype" Multimedianwendungen ermöglichen, bei denen ein ungewohntes Layout üblich ja sogar erwünscht sind? Jedenfalls lassen die von mir bisher gesehenen Video-Beispiele diesen Eindruck nicht als abwegig erscheinen.

Ich weiss auch nicht wie sinnvoll es ist ein x-tes Cross Framework "selbst" zu erfinden, anstelle eines der bewährten und von hunderten wenn nicht sogar tausenden Peogrammierern gewarteten Frameworks einzusetzen. Besteht da nicht die Gefahr, dass sich Embarcadero damit überfordert? Wie mir scheint, sind da bereits mächtigere und finanzkräftigere Firmen daran gescheitert, eigene Frameworks durchzusetzen.

[edit]Aber trotz allem bin ich gespannt Firemonkey mal selbst einzusetzen und werde es ohne Vorurteile und mit viel Hoffnungen prüfen. Wenn da nicht die Lizenzrichtlinien von Apple so restriktiv wären (kein OSX in einer VM), werde prüfen müssen, ob wir uns ein Apple-Rechner leisten können. Wird also etwas teuer wenn ich Firemonkey ausreizen möchte.[/edit]

[Insider2004]

Wie war. Es gab ja schon ein sehr mächtiges Framework: Qt. Es kann praktisch alles, was Windows auch kann. Leider ist es in C++ geschrieben. D.h. es hätte einen maximalen Interface-Horror gegeben und EMB hätte keinen alleinigen Zugriff auf die Sourcen gehabt. Jetzt fangen sie halt mit FM bei Null an. Ich schätze das dauert 5 Jahre bis die Fehler draußen sind und man in den Produktiv-Einsatz gehen kann.

[Insider2004]

Was ich auch befürchte ist, dass die Power allmählich nachlässt und FM nicht mehr richtig weiterentwickelt wird. Der Mac-Anteil beträgt ja nur 5% bei den Desktop-Geräten. Windows liegt noch immer bei ca. 90%. Die werden genau schauen, wo die Kohlen herkommen bei der Kundschaft.