0-Based Strings ab XE4

[Bernhard Geyer]

Abgezweigt vom Thema Das with-Statement in XE4

Zitat:

Zitat von jensw_2000 (Beitrag 1212358)

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:

Zitat von jensw_2000 (Beitrag 1212358)

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:

Zitat von jensw_2000 (Beitrag 1212358)

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

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

Zitat von bernau (Beitrag 1212373)

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

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

Zitat von RWarnecke (Beitrag 1212376)

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:

Zitat von RWarnecke (Beitrag 1212376)

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:

Zitat von jensw_2000 (Beitrag 1212369)

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:

Zitat von Bernhard Geyer (Beitrag 1212371)

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:

Zitat von Bernhard Geyer (Beitrag 1212371)

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:

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!

[bernau]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1212375)

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.

[Bernhard Geyer]

Zitat:

Zitat von jensw_2000 (Beitrag 1212380)

Dann Wenn dann irgendwann die klasischen Stringfunktionen sie Pos und Copy auf zerobased Strings umgebaut werden,

Wirds nicht. Wenn dann gibt es sie nicht mehr. Es macht keinen Sinn neben den objektoriertierten Ansatz einer Methode String.IndexOf noch die alte Funktion Pos zu haben.

Intern kann man es die Pos-Methode umschreiben auf

function Pos(const SubString, S: String): Integer;
begin
result := S.IndexOf(SubString) + 1;
end;

[jaenicke]

Da XE4 nun raus ist, können wir ja selbst reinschauen wie es konkret darin aussieht:
https://downloads.embarcadero.com/free/rad_studio

[jensw_2000]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1212384)

Intern kann man es die Pos-Methode umschreiben auf

function Pos(const SubString, S: String): Integer;
begin
result := S.IndexOf(SubString) + 1;
end;

Diese neue Pos Funktion wird es "dann" hoffentlich in den sysutils geben, genau wie alle anderen "klassischen" Stringfunktionen...

[Bernhard Geyer]

Zitat:

Zitat von jaenicke (Beitrag 1212385)

Da XE4 nun raus ist, können wir ja selbst reinschauen wie es konkret darin aussieht:
https://downloads.embarcadero.com/free/rad_studio

Das beste ist das es nur 50/60 € für XE3-User kostet.
Damit dürften die Aufschreie etwas kleiner werden (die zuvor wegen 500 € Mobile Pack entstanden sind) :-)

[Namenloser]

Welchen Unterschied macht es denn, ob der String mit 0 oder mit 1 anfängt? Ich meine, ich persönlich fände es zwar schöner, wenn Strings wie Arrays mit 0 anfangen würden, da es einheitlicher und mathematisch gesehen schöner ist, aber eigentlich ist es doch eine Frage der Konvention...

[Union]

Naja, den Unterschied macht, dass es bisher in der Delphi Language anders war. Und die direkte Indexierung oft u.a. aus Performancegründen eingesetzt wurde.

[Namenloser]

Zitat:

Zitat von Union (Beitrag 1212392)

Naja, den Unterschied macht, dass es bisher in der Delphi Language anders war.

Ich meinte eher, dass ich keinen Grund sehe, warum man das ändern sollte. Bzw. halte ich den Aufwand für unverhältnismäßig.

Ansonsten, wenn man da schon anfängt, könnte man gleich eine Delphi Language 2.0 rausbringen und mal ganz generell bei den Altlasten aufräumen... was ich mir einerseits manchmal wünschen würde, aber wenn ich ehrlich bin, glaube ich, dass das der Untergang von Delphi wäre, da es eben heutzutage hauptsächlich von der Wartung von alten Projekten lebt...

[stahli]

Na ja, wenn man jetzt erst die Programmierung erfinden würde ich vorschlagen, in Listen, Arrays und Strings m.E. immer und überall bei 1 anfangen zu zählen.
Dann könnte man auch das Count - 1 einsparen.

Aber ich werde nicht den Versuch unternehmen, das ernsthaft durchsetzen zu wollen. :stupid:
Generell 0-basiert ist dann m.E. die zweitbeste Lösung (weil eindeutig und nicht missverständlich, gerade für Neueinsteiger).

[RWarnecke]

Zitat:

Zitat von stahli (Beitrag 1212400)

Na ja, wenn man jetzt erst die Programmierung erfinden würde ich vorschlagen, in Listen, Arrays und Strings m.E. immer und überall bei 1 anfangen zu zählen.
Dann könnte man auch das Count - 1 einsparen.

Gerade den Count - 1 bekommste doch in jedem Lehrbuch eingebleut, war zumindest in meinen Büchern so. Und Du musst nicht immer Count-1 schreiben. Nehme einfach die Funktion Pred(), die macht das passend.

Zitat:

Zitat von stahli (Beitrag 1212400)

Aber ich werde nicht den Versuch unternehmen, das ernsthaft durchsetzen zu wollen. :stupid:
Generell 0-basiert ist dann m.E. die zweitbeste Lösung (weil eindeutig und nicht missverständlich, gerade für Neueinsteiger).

Nee, finde ich nicht so. Ich habe bis jetzt bei jeder Schleife, wo ich irgendwas durchgegangen bin immer mit 0 angefangen zu zählen.

[stahli]

Um die Realität abzubilden (z.B. in einem Geschäftsprozess in 10 Äpfel jeweils 2 Maden zu implementieren) würde man immer bei 1 anfangen zu zählen.
Bei 0 ist m.E. unlogisch (auch wenn man das von Anfang an lernt und sich das jetzt nicht mehr ändern lässt).
Mich hat das schon immer gestört. Aber wir sollten das hier nicht überdiskutieren (bringt ja eh nix ;-)).

[RWarnecke]

Zitat:

Zitat von stahli (Beitrag 1212412)

Aber wir sollten das hier nicht überdiskutieren (bringt ja eh nix ;-)).

Ganz Deiner Meinung.

[jensw_2000]

Zitat:

Zitat von NamenLozer (Beitrag 1212397)

... da es eben heutzutage hauptsächlich von der Wartung von alten Projekten lebt...

Genau das ist der Punkt.

Die Abwärtskompatibilität von vorhandenem Code war immer ein riesen Plus für Delphi.
Ich hatte einige Delphi 3 Programme, die ich mit wenigen kleinen Anpassungen problemlos in XE2 weiter bearbeite konnte.
Theoretisch sollten viele TP Programme mit 1-2 Anpassungen in der Projektdatei auch noch unter XE3 funktionieren.

Dieser "Investitionsschutz", in Bezug auf investierte Arbeitszeit, war für mich ausschlaggebend, als ich mit Delphi 7 irgendwann angefangen habe kommerziell zu programmieren. Ich kann nicht verstehen, dass man nun damit beginnt, absolut grundlegende Sprachfeatures einzureißen und genau diesen Vorteil wegzuwerfen.

[Bernhard Geyer]

Zitat:

Zitat von NamenLozer (Beitrag 1212397)

Ansonsten, wenn man da schon anfängt, könnte man gleich eine Delphi Language 2.0 rausbringen und mal ganz generell bei den Altlasten aufräumen... was ich mir einerseits manchmal wünschen würde,

Ist doch gemacht. Nennt sich Oxygene. Ist halt nur nicht vom gleichen Hersteller wie Delphi.

[Bernhard Geyer]

Zitat:

Zitat von stahli (Beitrag 1212400)

Dann könnte man auch das Count - 1 einsparen.

wo braucht man in modernen Programmiersprache ein Count - 1?
Vermutlich wird mittlerweile ein Großteil der C#/.NET-Entwickler nicht mal wissen das man Arrays/Liste auch mit einer einfachen Schleife statt einem for each-Konstrukt durchlaufen kann :-)

[sh17]

Zitat:

Zitat von bernau (Beitrag 1212381)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1212375)

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.

[Furtbichler]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1212427)

wo braucht man in modernen Programmiersprache ein Count - 1?
Vermutlich wird mittlerweile ein Großteil der C#/.NET-Entwickler nicht mal wissen das man Arrays/Liste auch mit einer einfachen Schleife statt einem for each-Konstrukt durchlaufen kann :-)

Also man benötigt das schon, wenn man z.B. den Index für Berechnungen verwenden muss. Und damit dürfte der Großteil der C#/Java/usw-Entwickler schon wissen, wie man Arrays per 'for' durchläuft. Allerdings wird das in Zeiten von LINQ auch immer seltener...

Zitat:

Zitat von Daniel (Beitrag 1212437)

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

Deine gutgemeinten Ratschläge und Tipps halte ich jetzt eher für einen Workaround als für solide Programmierung.

Der Wechsel des String-Paradigmas von 1- auf 0-basiert ist ein dermaßen harter Einschnitt, das man den konsequent gehen muss. Ohne Wenn und Aber. Die alten Programme sind dann eben nicht mehr mit XE3/XE4 kompilierbar. Oder man geht das Risiko ein und ändert den Code. Da die meisten eh nichts von automatisierten Tests halten (reiner Erfahrungswert, kein Vorwurf), wird das eine schöne Achterbahnfahrt ohne Sicherheitsgurt.

Ich habe z.B. eine sehr große Anwendung unter D6. Die werde ich nicht portieren. Der Kunde zahlt es nicht und es wäre Selbstmord. Also habe ich bis ich in Rente gehe eine VM mit D6 am Laufen.

[mjustin]

Was bedeutet diese Änderung für Entwickler von Komponenten und Bibliotheken für Delphi (und wie in meinem Fall auch Free Pascal), die Versionen ab 2009 oder älter untersützen wollen - nach Möglichkeit aus einer einzigen Codebasis?

Sind IFDEFs eine Lösung oder sieht es düsterer aus? :gruebel:

[Union]

Zitat:

Zitat von mjustin (Beitrag 1212454)

Was bedeutet diese Änderung für Entwickler von Komponenten und Bibliotheken für Delphi

Viel, viel Arbeit.

[mjustin]

Zitat:

Zitat von Union (Beitrag 1212455)

Zitat:

Zitat von mjustin (Beitrag 1212454)

Was bedeutet diese Änderung für Entwickler von Komponenten und Bibliotheken für Delphi

Viel, viel Arbeit.

Ach, echt? Dann werde ich gleich mal eine neue Kaffemaschine ordern :-D

[Daniel]

Zitat:

Zitat von Furtbichler (Beitrag 1212443)

Ich habe z.B. eine sehr große Anwendung unter D6. Die werde ich nicht portieren. Der Kunde zahlt es nicht und es wäre Selbstmord. Also habe ich bis ich in Rente gehe eine VM mit D6 am Laufen.

Von D6 auf iOS ... dass das mit gewissem Aufwand verbunden ist, das ist ... sagen wir ... "wenig überraschend". Die String-Änderungen betreffen den NEXTGEN-Compiler.

[sh17]

Na das mit der Konstante ist gar nicht mal schlecht

Delphi-Quellcode:

const FIRSTINDEX = 1;

if Pos('xy',string)>=FIRSTINDEX then ...

[Daniel]

Ja, aber eben in diesem Fall nicht pauschal auf "1" setzen, sondern die Dynamik nutzen:

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
const
  thirdChar = Low(string) + 2;
var s : string;
begin
  s:= 'Hallo';
  ShowMessage( s[thirdChar] );
end;

Der "Witz" dabei, dass die Funktion "Low()" hier keine konkrete Variable, sondern den String-Typ als solchen bekommt.