Quo vadis Delphi XE8 ?

[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.