Delphi XE4 FAQ

[mjustin]

Zitat:

Zitat von Insider2004 (Beitrag 1212183)

Habe gerade in den Releasenotes gelesen, dass XE4 und XE3 Windows XP nicht mehr offiziell unterstützen.

Betrifft mich zum Glück nicht - arbeite mit Windows 2000 :spin2:

[sh17]

Na da werde ich xe4 mal großzügig auslassen

[Codehunter]

Ich bin vor etwa 4 Jahren von D5 auf D7 migriert. XE2 ist zwar schon ne Weile in der Pipeline, allerdings sind da so viele Komponenten die ich verwende inkompatibel (grad x64, nenne nur TB2K und SpTBX) dass es wohl wieder 7 Jahre dauern wird bis ich den nächsten großen Wechsel mache. Ich kann mir das erlauben da die meisten meiner Projekte sehr konservativ sind. Aber als Early Adopter ist man doch bei Emba der Depp.

[Insider2004]

Bei Kundenbezug ist konservatives SW-Engineering sowieso sehr ratsam.

[jaenicke]

Zitat:

Zitat von sh17 (Beitrag 1212204)

Na da werde ich xe4 mal großzügig auslassen

Ich glaube auch nicht, dass es wichtig ist, sofern man nicht für iOS entwickeln will. Wir werden sicher upgraden, aber nur weil wir dank SA nichts dafür zahlen müssen.

[Bernhard Geyer]

Zitat:

Zitat von Codehunter (Beitrag 1212208)

(grad x64, nenne nur TB2K und SpTBX)

Also bei den SpTBX steht in den Release-Notes von 2012 XE2 und 64-Support drin. Und falls TB2K nicht eingestellt wurde sollte diese auch unter XE2 laufen.
Falls nicht wäre es an der Zeit solche Komponenten mit aktiv weiter entwickelte Komponenten zu ersetzen.

Zitat:

Zitat von Codehunter (Beitrag 1212208)

Aber als Early Adopter ist man doch bei Emba der Depp.

Wenns in Bezug auf Komponenten ist: Was kann Emba dafür das diese nicht zeitnah angepasst werden?

[Bernhard Geyer]

Zitat:

Zitat von Insider2004 (Beitrag 1212183)

Die Compileränderungen düften ganz Interessant sein, vor allem, weil es die im Desktop nicht gibt.
http://docwiki.embarcadero.com/RADSt...hanges_for_XE4

Ich sehe hier eher die Aufschreie im Bezug auf das String-Handling falls irgendwann mal die neuen Compiler die Desktop-Compiler beerbt bzw. die Basis davon darstellen werden:

- Seven of the older string types are not supported (Wie groß war der Aufschreib als String = Unicodestring wurde
- 0-based instead of 1-based (requiring possible changes to string handling routines) (Da heißt es jede MyString[x]-Codezeile anzupacken :-(

[sh17]

Da stand auch was von,das strings konstanten sind und nicht mehr variabel in der länge,kann gerade nicht nachschauen

[Robotiker]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1212233)

Ich sehe hier eher die Aufschreie im Bezug auf

Es ist eher so, dass die Inkonsistenzen, die schon im C++ Builder XE3 auftauchten, jetzt auch in Delphi erscheinen.

Der (alte) 32-Bit C++ Compiler und der neue 64-Bit C++ Compiler sind auch sehr unterschiedlich, was den unterstützten Sprachumfang angeht.

Zitat:

No, XE4 will not have C++11 for 32-bit. C++11 is only in the 64-bit compiler,
which is based on the LLVM CLang compiler. The 32-bit compiler is still
the same Borland/Embarcadero compiler it always has been. The eventual
goal is to migrate the 32-bit compiler to the same LLVM CLang architecture,
but that is not happening just yet.

Quelle:
https://forums.embarcadero.com/threa...5794&tstart=45

Es wurde schon argumentiert, neue Programme seien sowieso 64 Bit, also sei kein neuer 32-Bit Compiler mehr erforderlich. Das passt aber nicht damit zusammen, dass der C++ Compiler für den Mac auch auf dem alten 32-Bit Compiler basiert.

Man gewinnt schon den Eindruck, mit dieser nativen Multi-Plattform Entwicklung in gleich zwei Programmiersprachen haben sie sich mehr vorgenommen, als sie leisten können.

[hanspeter]

Was ist eigentlich mit ARC – Automatic Reference Counting?
Ist das auch für VCL - Compiler verfügbar?
Und was ist mit dem Wegfall einer Reihe von Stringtypen?
Wenn der alte Delphicompiler doch mal abgelöst werden sollte, ob sich das durchschlägt? (Wäre ein nogo)
Da sich seit XE für die VCL nichts Wesentliches mehr getan hat, hat es ohnehin den Anschein als ob dieser Entwicklungszweig ein Auslaufmodell ist.
Mit Firemonkey sind wir bei Umstellversuchen mit XE2 etwas auf die Nase gefallen.
Lag aber hauptsächlich an der Unausgereiftheit des Produktes.
Bei einer sehr umfangreichen Codebasis Delphi-Code ist der Umstellaufwand auf Firemonkey ziemlich hoch.
Wir sind intensiv am Überlegen, ob Prism/Oxygene nicht der erfolgversprechendere Weg ist.
Gibt es da schon Erfahrungen zum Umstellungsaufwand ?
Den Wegfall von Prism in Delphi sehe ich an dieser Stelle eigentlich eher positiv.


Peter