0-Based Strings ab XE4

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