0-Based Strings ab XE4

[Bernhard Geyer]

Ein Wizard müsste von Emba her der einen bei der Umstellung hilft.
Oder GExperts/CnPack nehmen sich der Sache an.

Unicode würde ich nicht als vergleich her nehmen. Hier hat man einen großen Mehrwert (jedenfalls würde uns ohne ein wichtiges Merkmal fehlen und großkunden uns nicht mehr nehmen).

[bernau]

0-Basierte Strings gibt's z.Z. nur für iOS.

Im Win-Compiler bleibt es erst mal so. Wird aber früher oder später wohl angepasst werden.

Das heist: z.Z. müssen "nur" Unit's angepasst werden die du für IOS benötigst.

Wenn du diese für Win und IOS benötigst muss du entweder den Compilerswitch verwenden oder eine Logik einbauen.

Gilt übrigens nur für den Index-Basierten Zugriff. Copy, Insert etc. bleiben wohl 1-Basiert.

[SubData]

Das klingt irgendwie total nach halbfertig und nicht bis zum Ende durchdacht...

[Bernhard Geyer]

Zitat von bernau:

Gilt übrigens nur für den Index-Basierten Zugriff. Copy, Insert etc. bleiben wohl 1-Basiert.

Die alten Funktionen bleiben 1-Basiert, die neuen Methoden an der String-Klasse sind 0-Basiert.
Siehe auch http://docwiki.embarcadero.com/RADSt...d_Desktop_Apps

[bernau]

Zitat von Bernhard Geyer:

Die alten Funktionen bleiben 1-Basiert, die neuen Methoden an der String-Klasse sind 0-Basiert.
Siehe auch http://docwiki.embarcadero.com/RADSt...d_Desktop_Apps

Stimmt. Die waren aber auch schon in XE3 0-Basiert. Ändert sich also nix.

[sh17]

Zitat von bernau:

Zitat von Bernhard Geyer:

Die alten Funktionen bleiben 1-Basiert, die neuen Methoden an der String-Klasse sind 0-Basiert.
Siehe auch http://docwiki.embarcadero.com/RADSt...d_Desktop_Apps

Stimmt. Die waren aber auch schon in XE3 0-Basiert. Ändert sich also nix.

bloss gut das ich das gelesen habe.

d.h. wenn ich jetzt die StringHelper bei String verwende, muss ich 1 draufaddieren? Und mir alle Quellcodestellen markieren um dann bei der Umstellung die 1 wieder weg zu machen? Oder per IFDEF?

[Daniel]

Addieren und abziehen musst Du nur, wenn Du die alten und die neuen Funktionen mischst. Möchtest Du über einen kompletten String laufen, kannst Du die for...in - Schleife nutzen. Oder Du lässt Dir Dir low() und high() die jeweils korrekten Grenzen eines Strings liefern.
Wenn Du häufig auf die erste, dritte oder zwölfte Stelle eines Strings zugreifen müsst. Kannst Du Dir auch Konstanten definieren, die Dir den korrekten Index liefern: FIRST = low(s) oder THIRD = low(s)+2. Auch damit entbindest Du Dich von der Pflicht, manuell die Eins zu addieren.

[RWarnecke]

Ich finde die Diskussion ja recht interessant und es sind ja sicherlich auch ein paar Argumente zusammen gekommen. Ich habe zwar nur mehrere kleinere Projekte und ein Projekt was so ca. 10000 Zeilen umfasst, aber sind wir doch mal ehrlich, wie viele Stellen hat ein normales Programm (Keine Verschlüsselungsprogramm, Serialgenerator oder ähnliches), wo es einen String zerlegen muss ?

Da die 0-Based Strings in XE4 nur für den Bereich gilt, wo der LLVM-Compiler zum Einsatz kommt. Das heißt, für die reinen VCL-Programme ändert sich hier gar nichts bei XE4. Ich bin der Meinung, dass man hier warten sollte, bis es für die VCL auch soweit ist. Vielleicht baut ja Emba noch irgendwas ein, was die Diskussion in Luft auflöst und wenn Emba nichts macht, dann haben wir doch alle soviel Know-How, dass wir uns gerade einen Parser bauen können, der unsere Units durchgeht.

[jaenicke]

Zitat von RWarnecke:

aber sind wir doch mal ehrlich, wie viele Stellen hat ein normales Programm (Keine Verschlüsselungsprogramm, Serialgenerator oder ähnliches), wo es einen String zerlegen muss ?

Bei uns waren es sehr viele (Kassensoftware).

Zitat von RWarnecke:

Vielleicht baut ja Emba noch irgendwas ein, was die Diskussion in Luft auflöst und wenn Emba nichts macht, dann haben wir doch alle soviel Know-How, dass wir uns gerade einen Parser bauen können, der unsere Units durchgeht.

Hier sieht es so aus, dass bei neuem Code die expliziten nullbasierten Funktionen benutzt werden. Das macht vieles im Code auch einfacher, da man nicht ständig zwischen null- (Array) und einsbasiert (Strings bisher) wechseln muss.

So ist das ganze auch unabhängig von der Compilereinstellung immer nullbasiert und zukunftssicher.

Zitat von jensw_2000:

Kann sich noch jemand daran erinnern, wie ewig lange es damals beider Unicode Umstellung gedauert hat, bis alle Projekte, Komponenten und auch Delphi selbst wieder konsistent waren?

Nicht lange. Es gab danach noch ein paar Probleme, aber das waren alles vorher nicht sauber geschriebene Codestellen.

[jensw_2000]

Zitat von Bernhard Geyer:

Ein Wizard müsste von Emba her der einen bei der Umstellung hilft.

Sag ich doch. Den Teil hast Du nur nicht in diesen Thread kopiert.
Egal. Manuell darf so eine Umstellung allerdings nicht mehr erfolgen. Die Zeit bezahl einem kein Mensch ...

Zitat von Bernhard Geyer:

Unicode würde ich nicht als vergleich her nehmen. Hier hat man einen großen Mehrwert (jedenfalls würde uns ohne ein wichtiges Merkmal fehlen und großkunden uns nicht mehr nehmen).

Auch richtig. Unicode ist ein Muss. Aber der Aufwand für die Umstellung auf 0-based Strings ist vermutlich vergleichbar ... und diese Umstellung gibt es eigentlich nur, weil eine robuste klassische Win32 Programmiersprache langsam aber sicher vergewaltigt wird um eine von vorn herein grenzenbehaftete Cross-Platformunterstützung zu bieten. Das ist zumindest meine Meinung.

Zitat von RWarnecke:

wie viele Stellen hat ein normales Programm (Keine Verschlüsselungsprogramm, Serialgenerator oder ähnliches), wo es einen String zerlegen muss ?

Aber gerade das ist doch die Gefahr. Lauf doch mal alle Units der letzten 10 Jahre durch und versuche alle indizierten String-Zugriffe präzise zu ersetzen. Fehlerchance 50% weil "aString[1]" auch XE"5?" funktionieren wird. Nur eben mit dem fahschen Ergebnis.
Dann Wenn dann irgendwann die klasischen Stringfunktionen sie Pos und Copy auf zerobased Strings umgebaut werden, dann wird wegwerfen und neuschreiben einfacher!