0-Based Strings ab XE4

[jensw_2000]

Ja, Du hast Recht. Ein IFDEF zerhackter Code ist echt nicht schön. Neue Standard-Typen auch nicht.

Unter dem Strich muss aber eine Lösung her, die meine langjährig erarbeitete Codebasis nicht mit Version XE"n" in einen unbenutzbaren Zustand versetzt. Die Zeit, die für das Umschreiben der Quellcodes draufgeht holt kein tolles neues Delphi Feature wieder raus.

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?

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