Abgezweigt vom Thema Das with-Statement in XE4

Zitat von jensw_2000:

Warum sollen IFDEFS nicht gehen?

Gehen schon, aber du glaubst doch wohl nicht im ernst da Emba/der Hersteller so einen Wizard für Altcompatiblität herstellt.
WEnn dann wird man bei den Strings umstellen und das wars. Aber nicht den Quellcode entsprechend mit IFDEF's verseuchen.
Da es einenige Versionen mit 1 und 0-Basierten Zugriff geben wird ist die notwendigkeit auch gar nicht gegeben.

Zitat von jensw_2000:

Am schönsten wäre es aber, wenn der String ein "1-based String" bleibt und für die zerobased Strings einfach ein neuer Typ mit eigenem Namen eingeführt wird.

Das würde vermutlich mehr Probleme verursachen als Lösen. Tausende Funktionen für beide Typen anbinden bzw. u.U. Performancekrücken riskieren wenn automatisch immer gewandelt wird.

Zitat von jensw_2000:

... und "ZString"

ZString? Die Welt (.net/java) verwendet den Namen String für einen String und bei Dephi muss man jedesmal wieder den neuen Namen kennen?
Ich denke mit den neuen Methoden und dem 0basierten String vermeitet man in Zukunft Quellcodeportierungsprobleme.

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?

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

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.

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

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

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.

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.

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!

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.