Quo vadis Delphi XE8 ?

[Insider2004]

Wenn man sich so die SVN Folder im Netz anschaut, dann bekommt man schon wieder Schüttelfrost. Man wollte doch den String-Salat aufräumen, damit Anfänger sich besser in Delphi zurechtfinden (siehe UTF8 abschaffen etc.). Das hat man dann auch gründlich gemacht. Doch was müssen meine blutunterlaufenen Äuglein jetzt sehen!?!? LargeInt, LargeUInt, FixedInt, FixedUInt. Ich wette, denen fällt bestimmt noch mehr ein! Die Prozessorregister werden nicht mehr. Auch wenn man 10 weitere Typen einführt. Da wünsche ich dann noch fröhliches Typ-Raten im Informatikunterricht und den restlichen Delphi-Stuben auf der Welt!

BTW: scheinbar kennen die Ingenieure bei Emba nicht mehr den Unterschied zwischen generischen und fundamentalen Integern. Das geht bei denen wild drunter und drüber. Die wären vermutlich auch bei Niklaus Wirth durch das Vor-Diplom gefallen.

[Stevie]

Könnte das am Ende gar daran liegen? ...

[Daniel]

Das ist grundsätzlich nichts Neues.
Wir haben Datentypen, die plattformabhängig sind und welche, die plattformunabhängig sind.

Die Datentypen sind allesamt hier dokumentiert:
http://docwiki.embarcadero.com/RADSt..._Integer_Types

Das Zielsystem gibt die jeweiligen Spielregeln vor - alles andere würde wenig Sinn machen, schliesslich wollen wir ja gerade die Interoperabilität mit den jeweiligen Systemen. Und nun eben auch mit iOS64.

[himitsu]

Jupp, leider ist Emba daran mal nicht Schuld.

Immerhin waren die ja nicht die Ersten, werlche für 64 Bit eine Entwicklungsumgebung anboten (eher die Letzten :zwinker:)
und da waren Andere (Microsoft, Intel usw.) schon vorher auf die geniale Idee gekommen und haben beschlossen den Integer-Typen einzufrieren und dafür einen neuen Typen einzuführen, welcher ab jetzt als dynamischer/plattformabhängiger System-Typ definiert wurde, der sich an die CPU anpasst.

In Delphi nannte er sich er sich dann NativeInt und NativeUInt.


Und im Grunde war GodeGear/Embarcadero wenigstens konsequent, als sie von ANI auf Unicode umstellten.
Es ist ja nicht deren Schuld, daß viele ihren Code "schrottig" schrieben, indem sie z.B. PChar verwendeten, obwohl sie eigentlich ausschließlich einen ANSI-String behandeln wollten, oder daß sie bei Verwendung von PChar nicht die Größe richtig "dynamisch" bestimmten.

Gut, beim Integer hatte man somit Pech, wobei Integer-Casts von und zu Pointern nicht wirklich richtig waren, denn auch dafür gibt es entsprechende Typen, wie z.B. IntPtr, welche auch jetzt noch richtig gearbeitet hätten.
Für die Parameter bei den Messages gab es auch schon immer die entsprechenden Typen WPARAM, LPARAM und LRESULT.

Und PChar, Char und String war per Definition auch schon lange vor 2009 als dynamisch/plattformabhängig definiert.
Außerdem hätte man wissen müssen, daß man Speicher und Übertragungsformate niemals plattformabhängig definiert, außer man schreibt den Typen mit ins Protokoll.

Wer alles vorher richtig gemacht hatte, hatte bei Umstellungen auf Unicode oder 64 Bit keine oder zumindestens fast keine Probleme.



Wie man in Stevies Link sieht, war/ist es in C/C++ traditionell üblicher, daß es da viel mehr Typen gibt und diese speziell auf gewisse Bereiche ausgelegt sind, damit sich zukünftige Änderungen genauer anpassen.
In Pascal versuchte man das einfacher zu halten und fasste viele Typen quasi zusammen und leider wurde der Integer, Char und PChar zu oft für falsche Dinge eingesetzt, auch wenn sich Herr Wirth und Andere schon ein paar Gedanken gemacht hatten und für gewisse Dinge spezielle Typen einführten.

[Mavarik]

Zitat:

Zitat von himitsu (Beitrag 1289687)

Und im Grunde war GodeGear/Embarcadero wenigstens konsequent, als sie von ANI auf Unicode umstellten.
Es ist ja nicht deren Schuld, daß viele ihren Code "schrottig" schrieben, indem sie z.B. PChar verwendeten, obwohl sie eigentlich ausschließlich einen ANSI-String behandeln wollten, oder daß sie bei Verwendung von PChar nicht die Größe richtig "dynamisch" bestimmten.

Naja... Apple macht es anders... Da ist ein Char auch unter 64Bit immer noch 1 Byte lang (Wenn ich die Tabelle richtige verstehe)

[OT]
Hätte EMBA das auch gemacht, würden nicht so viele Projekte noch auf D2007 hängen... Und es gäbe nicht die "Unicode-Hürde".
Ja ja ja die VCL... Schon klar... Hätte man zweigleisig fahren müssen...Ein schönen Compilerswitch welche Version gelinkt werden soll....[/OT]

Mavarik

[Bernhard Geyer]

Zitat:

Zitat von Mavarik (Beitrag 1289853)

Naja... Apple macht es anders... Da ist ein Char auch unter 64Bit immer noch 1 Byte lang (Wenn ich die Tabelle richtige verstehe)
[OT]
Hätte EMBA das auch gemacht, würden nicht so viele Projekte noch auf D2007 hängen... Und es gäbe nicht die "Unicode-Hürde".

Apple hat eine dem String-Type entsprechenden Typ CFString und der Arbeitet mit UniChar. Wenn man diesen Verwenden und die dafür vorgesehen Zugriffsfunktionen wird man (ähnlich wie bei der MFC mit CString) relativ wenig mitbekommen haben als man auf Unicode umgestiegen ist.
Bei Delphi konnte man viele Jahre "faulenzen" und die Compilermagic verwenden statt sich an den relevanten Stellen (Datei speichern, APIs, ...) Gedanken machen zu müssen.
Mit D2009 musste halt diese Stellen angepasst werden. Wenns man richtig gemacht hat waren es nicht zu viele.

Zitat:

Zitat von Mavarik (Beitrag 1289853)

Ja ja ja die VCL... Schon klar... Hätte man zweigleisig fahren müssen...Ein schönen Compilerswitch welche Version gelinkt werden soll....[/OT]

Man kann per Unit diesen Schalter setzten bis man diese gefixt hat. Aber dies Diskussion wieso und wieso nicht gabs schon öfter.

[himitsu]

Nein PChar muß 2 Byte sein, denn PChar ist das Äquivalent zum String, welches na nun ein Alias für den UnicodeString ist.

Ja, man hätte natürlich auch den String als Alias für einen UTF8String nehmen können, dann wäre PChar 1 Byte geblieben,
aber dann müsste man für alle WinAPIs einen Wrapper bauen können, da es Diese nur als ANSI oder UTF-16 (Unicode) gibt.

So paßt nun der PChar genau auf die Unicode-Versionen der WinAPIs drauf.

[mkinzler]

Zitat:

Naja... Apple macht es anders... Da ist ein Char auch unter 64Bit immer noch 1 Byte lang (Wenn ich die Tabelle richtige verstehe)

Es macht aber ein Unterschied, ob man eine Entscheidung als Betriebssystemhersteller ( Apple) oder als ( nicht führender) Hersteller von Entwicklungssoftware ( CodeGEAR/EMBT) trifft.
Der Unicodesschnitt war hart aber richtig.

Zitat:

Hätte EMBA das auch gemacht, würden nicht so viele Projekte noch auf D2007 hängen... Und es gäbe nicht die "Unicode-Hürde".

Dann wären die Projekte vielleicht auf neue Versionen gehoben, aber immer noch nicht unicodefähig.
Es wäre eher wie mit der BDE, solange es diese gibt, besteht kein Zwang sich von ihr zu verabschieden.

[Bernhard Geyer]

Zitat:

Zitat von mkinzler (Beitrag 1289871)

Zitat:

Naja... Apple macht es anders... Da ist ein Char auch unter 64Bit immer noch 1 Byte lang (Wenn ich die Tabelle richtige verstehe)

Es macht aber ein Unterschied, ob man eine Entscheidung als Betriebssystemhersteller ( Apple) oder als ( nicht führender) Hersteller von Entwicklungssoftware ( CodeGEAR/EMBT) trifft.
Der Unicodesschnitt war hart aber richtig.

Ein Char bleibt ein Char, aber zur speicherung von Text werden in den String-Klassen UniChars verwendet :-)

Zitat:

Hätte EMBA das auch gemacht, würden nicht so viele Projekte noch auf D2007 hängen... Und es gäbe nicht die "Unicode-Hürde".

Dann wären die Projekte vielleicht auf neue Versionen gehoben, aber immer noch nicht unicodefähig.[/QUOTE]
Ich glaube auch das viele Projekte bei D2007 hängen geblieben sind da durch die VCL.NET (und des generellen .NET-Ausflugs) viel Entwicklungszeit investiert wurde den man danach wegschmeißen konnte. Das dürfte für einige Firmen das Ende bedeutet

Zitat:

Es wäre eher wie mit der BDE, solange es diese gibt, besteht kein Zwang sich von ihr zu verabschieden.

Dast stimmt. Da würde auch noch die Forderung kommen Chars genauso unter iOS, Android und OSX mit 1 Byte pro Character zu haben.

[himitsu]

Frag mal den Andreas ... die 1-Byte-Chars/Strings gibt es noch. (heimlich versteckt)

Auch wenn ich nicht wirklich verstanden hab, warum man das ANSI/UTF-8 abgeschafft hat.

[jaenicke]

Zitat:

Zitat von himitsu (Beitrag 1289882)

Auch wenn ich nicht wirklich verstanden hab, warum man das ANSI/UTF-8 abgeschafft hat.

Weil es leider in vielen Fällen ohne Not einfach so benutzt wird. Oft aus Unkenntnis, oft aus Bequemlichkeit. Selbst in zwei Projekten, die Andreas Unit verwenden, wird es offenbar einfach nur verwendet, damit es Ansi ist, obwohl es dort gar keinen Grund dafür gibt. Nur funktioniert die App nur dadurch nicht z.B. mit chinesischer Sprache (ist aber auch nicht im AppStore).

Deshalb kann ich den Schritt durchaus nachvollziehen...

Es gibt aber natürlich auch seltene Fälle, in denen Ansistrings tatsächlich Sinn machen, auch auf mobilen Plattformen. Zum Beispiel, wenn man mit einem Dienst direkt kommuniziert, der Ansistrings benutzt.

[Stevie]

Zitat:

Zitat von jaenicke (Beitrag 1289905)

Es gibt aber natürlich auch seltene Fälle, in denen Ansistrings tatsächlich Sinn machen, auch auf mobilen Plattformen. Zum Beispiel, wenn man mit einem Dienst direkt kommuniziert, der Ansistrings benutzt.

Da kann man doch aber problemlos TBytes hin und her ballern und das per TEncoding lösen oder?

[CHackbart]

Wenn jch überlege was für Verrenkungen ich bei Synapse TCP machen musste. Es macht keinen Sinn den Entwickler zu bevormunden. Fast jede Lowlevel API verlangt nach Ansi und da dauernd Verrenkungen einbauen zu müssen ist eher eine Gängelung.

[jaenicke]

Zitat:

Zitat von Stevie (Beitrag 1289906)

Da kann man doch aber problemlos TBytes hin und her ballern und das per TEncoding lösen oder?

Das ist auch der bessere Weg, aber besser ist nicht einfacher und deshalb möchten viele den Weg nicht bestreiten. ;-)

[jbg]

Für mich persönlich wäre es schön, wenn zumindest UTF8String zur Verfügung stehen würde. Auf den ANSI-String kann ich verzichten. Aber UTF8 ist der Quasi-Standard des Internets. Und laufend mit TBytes herumzuhantieren macht da wenig Spaß.

Was sieht wohl leserlicher aus (und nein, ich werden Byte nicht in WideChar konvertieren was ein unnötiges "MOVZX" einfügen würde):

Delphi-Quellcode:

B[I] in [Ord('A')..Ord('Z'), Ord('a')..Ord('z'), Ord('_'), Ord('0')..Ord('9')]
// oder
S[I] in ['A'..'Z', 'a'..'z', '_', '0'..'9']

[jaenicke]

Da stimme ich zu, mit UTF-8 sieht das anders aus. Ich wandele allerdings immer zuerst in Unicodestrings um, so dass ich aktuell keine Probleme habe.

[Bernhard Geyer]

Zitat:

Zitat von jbg (Beitrag 1289914)

Was sieht wohl leserlicher aus (und nein, ich werden Byte nicht in WideChar konvertieren was ein unnötiges "MOVZX" einfügen würde):

Delphi-Quellcode:

B[I] in [Ord('A')..Ord('Z'), Ord('a')..Ord('z'), Ord('_'), Ord('0')..Ord('9')]
// oder
S[I] in ['A'..'Z', 'a'..'z', '_', '0'..'9']

Ich denke dafür kann man auch eine überladene Version von CharInSet definieren um sowas zu verstecken

[Bernhard Geyer]

Zitat:

Zitat von jaenicke (Beitrag 1289915)

Da stimme ich zu, mit UTF-8 sieht das anders aus. Ich wandele allerdings immer zuerst in Unicodestrings um, so dass ich aktuell keine Probleme habe.

Man sollte seine Anwendung so gestallten das nur an den "Außenkontaktstellen" in die nötige Charset/Codepage/Codierung gewandelt wird und intern 100% mit UnicodStrings gearbeitet wird.

[jbg]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1289917)

Man sollte seine Anwendung so gestallten das nur an den "Außenkontaktstellen" in die nötige Charset/Codepage/Codierung gewandelt wird und intern 100% mit UnicodStrings gearbeitet wird.

Und was macht ein JSON Parser der UTF8 "on the fly" bekommt? Einfach mal zwischen einer multi-byte UTF8-Sequence in UTF16 konvertieren dürfte interessante Ergebnisse liefern. Am Ende spuckt er schon einen UTF16-"Baum" aus, aber zum Parsen nutzt er UTF8.

Zitat:

Ich denke dafür kann man auch eine überladene Version von CharInSet definieren um sowas zu verstecken

Pfui. CharInSet ist für einen Parser der letzte Unsinn. Der Compiler generiert für CharSets mit nur ASCII-Zeichen den korrekten Code. Da muss man nicht aus einer optimierten "Set-Abfrage" die komplett in den CPU Registern abläuft, einen Funtionsaufruf und Bit-Operationen auf RAM durchführen. Wenn ich bei Embarcadero arbeiten würde, wäre CharInSet sicherlich meine erste Wahl, da dort "langsam und schlecht" seit ein paar Jahren vorherrscht.

[Bernhard Geyer]

Zitat:

Zitat von jbg (Beitrag 1289918)

Und was macht ein JSON Parser der UTF8 "on the fly" bekommt? Einfach mal zwischen einer multi-byte UTF8-Sequence in UTF16 konvertieren dürfte interessante Ergebnisse liefern. Am Ende spuckt er schon einen UTF16-"Baum" aus, aber zum Parsen nutzt er UTF8.

Die JSON-Schnittstelle ist für mich Außenschnittstelle. Und dieser liefert ja mittlerweile Emba. Und sobald ich die Wert einlese habe ich ja normale Unicodestrings.

Zitat:

Zitat von jbg (Beitrag 1289918)

Zitat:

Ich denke dafür kann man auch eine überladene Version von CharInSet definieren um sowas zu verstecken

Pfui. CharInSet ist für einen Parser der letzte Unsinn. Der Compiler generiert für CharSets mit nur ASCII-Zeichen den korrekten Code. Da muss man nicht aus einer optimierten "Set-Abfrage" die komplett in den CPU Registern abläuft, einen Funtionsaufruf und Bit-Operationen auf RAM durchführen. Wenn ich bei Embarcadero arbeiten würde, wäre CharInSet sicherlich meine erste Wahl, da dort "langsam und schlecht" seit ein paar Jahren vorherrscht.

Den Quellcode habe ich mir hier noch nicht angesehen um das zu beurteilen. Da ich aber keine Zeitkritische Operation mit viele CharInSet-Abfragen habe ist mir hier auch nix aufgefallen.

[Dejan Vu]

Zitat:

Zitat von jbg (Beitrag 1289914)

Was sieht wohl leserlicher aus (und nein, ich werden Byte nicht in WideChar konvertieren was ein unnötiges "MOVZX" einfügen würde):

Delphi-Quellcode:

B[I] in [Ord('A')..Ord('Z'), Ord('a')..Ord('z'), Ord('_'), Ord('0')..Ord('9')]
// oder
S[I] in ['A'..'Z', 'a'..'z', '_', '0'..'9']

Beides ist bezüglich Lesbarkeit Müll. Lesbar ist imho eh nur etwas wie

Delphi-Quellcode:

IsValidIdentifierChar(myChar)

. Und wie die jetzt intern arbeitet, ist mir egal.

[jbg]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1289923)

Die JSON-Schnittstelle ist für mich Außenschnittstelle. Und dieser liefert ja mittlerweile Emba. Und sobald ich die Wert einlese habe ich ja normale Unicodestrings.

Hätte Emba da mal lieber eingekauft, statt das selbst zu fabrizieren. Die Performance, vor allem unter Android, ist unterirdisch. Wofür andere Implementierungen unter 5 Sekunden brauchen, da verbrät die Embt-Variante 30 Sekunden (mein Nexus 5) und verschlingt auch noch unmengen an RAM: 3 GB für eine 180 MB große JSON Datei (Benchmark)

[Mavarik]

Zitat:

Zitat von mkinzler (Beitrag 1289871)

Dann wären die Projekte vielleicht auf neue Versionen gehoben, aber immer noch nicht unicodefähig.
Es wäre eher wie mit der BDE, solange es diese gibt, besteht kein Zwang sich von ihr zu verabschieden.

Das mag zwar sein, aber wie viele Leute brauchen den Unicode?
Hätte man das in Projekt XY gebraucht, hätte man sicherlich schon eine Fremdkomponente dafür benutzt und es wäre keine "Hürde"...

Mavarik

[Mavarik]

Zitat:

Zitat von himitsu (Beitrag 1289859)

Nein PChar muß 2 Byte sein, denn PChar ist das Äquivalent zum String, welches na nun ein Alias für den UnicodeString ist.

Emm nöö

Zitat:

Zitat von Apple

Delphi-Quellcode:

Table 1-1  Size and alignment of integer data types in OS X and iOS
Integer data type   ILP32 size   ILP32 alignment LP64 size LP64 alignment
char                 1 Byte           1 Byte       1 Byte     1 byte

Oder verstehe ich das falsch... Hat mich schon gewundert... Weil das ist doch "schon immer" Unicode, oder?

Mavarik

[Bernhard Geyer]

Zitat:

Zitat von Mavarik (Beitrag 1289944)

Das mag zwar sein, aber wie viele Leute brauchen den Unicode?

Mit Sicherheit genügend. Nicht umsonst gibt es einige Bibliotheken die für alte Delphi-Versionen das Problem halbwegs gelöst haben.
Und du solltest so eine Frage nicht bei den Delphi-Entwicklern stellen die (damals) noch mit Delphi arbeiten sondern bei denen die nicht mehr mit Delphi arbeiten. Ein grund wird fehlender Unicode-Support gewesen sein.

Zitat:

Zitat von Mavarik (Beitrag 1289944)

Hätte man das in Projekt XY gebraucht, hätte man sicherlich schon eine Fremdkomponente dafür benutzt und es wäre keine "Hürde"...

Solange die Basisimplementierung der VCL nicht Unicodefähig sind, stellen Fremkomponenten immer nur eine unnötig Komplexen "Fremdkörper" dar. Ich hätte mir damals (2002) sicherlich einige Arbeit sparen können wenn damals die VCL Unicodefähig gewesen wäre und ich nicht komplett auf WideString (glücklicherweise mit eigener Stringdefinition) umsteigen hätte müssen.

[Bernhard Geyer]

Zitat:

Zitat von Mavarik (Beitrag 1289946)

Zitat:

Zitat von himitsu (Beitrag 1289859)

Nein PChar muß 2 Byte sein, denn PChar ist das Äquivalent zum String, welches na nun ein Alias für den UnicodeString ist.

Emm nöö

Zitat:

Zitat von Apple

Delphi-Quellcode:

Table 1-1  Size and alignment of integer data types in OS X and iOS
Integer data type   ILP32 size   ILP32 alignment LP64 size LP64 alignment
char                 1 Byte           1 Byte       1 Byte     1 byte

Oder verstehe ich das falsch... Hat mich schon gewundert... Weil das ist doch "schon immer" Unicode, oder?

Mavarik

Schau dir mal die Definition von NSString und CFString bei Apple an. Dort ist ein Character auch 2 Byte groß. Wird halt UniChar genannt und nicht Char um keine Verwirrung zu verursachen.
Wäre Emb auch diesen Weg gegangen und hätte String/Char auf 1 Byte gelassen und den neuen Typ UnicodString/UnicodeChar eingeführt wäre der aufschrei mindestens genauso groß gewesen da ja jetzt kein Code mehr Compiliert ohne 2 Mio. Warnungen/Fehler zu bringen.

[Uwe Raabe]

Zitat:

Zitat von Mavarik (Beitrag 1289944)

Das mag zwar sein, aber wie viele Leute brauchen den Unicode?

Alle, deren Produkte für den internationalen Markt konzipiert sind.

Solange Amerikaner für den amerikanischen Markt programmieren und Deutsche für den deutschen Markt, haben beide ohne Unicode wohl keine nennenswerten Probleme. Aber wenn deine Software auch in Skandinavien, Griechenland, Tschechien, Russland, Israel, Iran, Japan und China eingesetzt wird, dann möchtest nicht mehr ohne Unicode arbeiten. Die verbleibenden Probleme sind schon genug.

[Dejan Vu]

Ich komme wegen TSiLang sehr gut ohne Unicode aus und verticke die Anwendungen zumindest in tschechisch (was pervers genug ist). Chinesisch sollte ich auch noch hinbekommen. Der Grund, von Delphi weggegangen zu sein, lag nicht am fehlenden Unicode-Support, das hatte andere Gründe.

[Bernhard Geyer]

Zitat:

Zitat von Dejan Vu (Beitrag 1289976)

Ich komme wegen TSiLang sehr gut ohne Unicode aus und verticke die Anwendungen zumindest in tschechisch (was pervers genug ist).

Tschechisch wird aber nur in tschechien gehen. Was macht einer Kunde in DE der z.B. tschechische Adressen mit verwalten will?
Und was ist an tschechisch pervers?

Zitat:

Zitat von Dejan Vu (Beitrag 1289976)

Chinesisch sollte ich auch noch hinbekommen.

Wird schwiriger. Chineisch lässt sich nicht auf eine Codepage reduzieren

Zitat:

Zitat von Dejan Vu (Beitrag 1289976)

Der Grund, von Delphi weggegangen zu sein, lag nicht am fehlenden Unicode-Support, das hatte andere Gründe.

Für dich mag das stimmen. Für andere ist Unicode-Support essentiell wichtig.

[Dejan Vu]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1289985)

Tschechisch wird aber nur in tschechien gehen. Was macht einer Kunde in DE der z.B. tschechische Adressen mit verwalten will?

Da hast Du natürlich vollkommen Recht. Das geht nur mit Unicode.

Zitat:

Zitat:

Zitat von Dejan Vu (Beitrag 1289976)

Chinesisch sollte ich auch noch hinbekommen.

Wird schwiriger. Chineisch lässt sich nicht auf eine Codepage reduzieren

Nun, die Oberfläche einer Maschinensteuerung kann man jedenfalls problemlos lokalisieren. Auch mit diversen Auswertetools hatte ich bisher keine Probleme. Aber es wird bestimmt schwieriger. Irgendwie. Irgendwo. Irgendwann.

Zitat:

Zitat:

Zitat von Dejan Vu (Beitrag 1289976)

Der Grund, von Delphi weggegangen zu sein, lag nicht am fehlenden Unicode-Support, das hatte andere Gründe.

Für dich mag das stimmen. Für andere ist Unicode-Support essentiell wichtig.

Das war -wie man unschwer erkennen kann- auch eine persönliche Aussage, die zudem nicht im Widerspruch zu deiner Aussage steht. Aber wenn Du darauf bestehst: Ich glaube trotzdem nicht, das der fehlende Unicode eine Hauptursache ist, weswegen sich Delphi-Jünger vom allmächtigen König David I. abgewendet haben: Sie mussten sich ja nur die TNT-Controls besorgen, der Datentyp an sich war ja schon länger bekannt. Das hatte imho wirklich andere Gründe (finde mal einen Delphientwickler z.B.). Aber letztendlich ist das alles Glaube und persönliche Erfahrung. Deine wird anders sein. Belassen wir es dabei.

[mkinzler]

Das Fehlen von Unicode-Unterstützung war sicherlich nicht "der" Grund für die Abwanderung, sondern ein möglicher Grund.
Fassen wir es allgemeiner: die fehlende Fähigkeit sich schnell an sich ändernde Rahmenbedingungen/ändernde Anforderungen anzupassen.

[Dejan Vu]

Weitere Vorschläge für einen Konsens:
"Niemand ist extra zu Delphi gewechselt, weil die Unicode-Unterstützung mangelhaft war."