Insert und NextGen

[himitsu]

Im NextGen wurde doch der Zeichenindex auf 0 verschoben.
Nun hätte ich angenommen, daß dann auch die Stringfunktionen entsprechend angepasst wurden. (Insert, Copy und Delete)

In der OH heißt es ja auch

Zitat:

Zitat von OH: Insert

In Delphi-Code fügt Insert Substr an der Position Dest[Index] in Dest ein.

Als ich es nun endlich mal testen konnte, macht Folgendes nicht das, was es angeblich sollte. :wall

Delphi-Quellcode:

Insert('"', Data, Low(Data));
Insert('"', Data, High(Data) + 1);

Wer ist denn nun auf diese saublode Idee gekommen das nur halb umzusetzen und vorallem warum?



Ich hatte auch schon überlegt die String-Helper zu benuzten, aber dann hängt es bei der vielgeschworenen Abwärtskompatibilität. (ich glaub die wurden erst in XE3 eingeführt)

[Daniel]

Die Funktionen "Insert()", "Copy()", "Pos()" und "Delete()" verhalten sich grundsätzlich wie früher und nutzen den 1-basierenden Index - aus Gründen der Abwärtskompatibilität.
Die neuen String-Helper zeigen grundsätzlich das neue Verhalten, nutzen also den 0-basierenden Index.

Das erlaubt es Dir, alten Code weiterhin zu nutzen.

[himitsu]

Jupp, daß die Helper immer mit 0 arbeiten, hatte ich schon mitbekommen.

Aber da der String umgebaut wurde, dachte ich, daß auch die Funktionen entprechend arbeiten, so wie man es durch die OH denken könnte.
Da steht auch, daß alles unter 1 auf 1 gesetzt wird, wobei im Code steht, daß alles unter 0 auf 0 gesetzt wird (wie ich vorhin beim Nachgesehn gesehn hab).


OK, daß heißt also, daß ich den halben Code wieder rauswerfen kann, wo ich bei diesen Funktionen das versucht hatte anzupassen. Ich hoffe nur das ändert sich nicht doch wieder irgendwann. :stupid:

Ist aber nicht sehr intuitiv, wenn man hier so und dort anders zählen muß. (im selben Compiler)
Jetzt nur noch schauen wie Pos arbeitet. :stupid:

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1296065)

Ist aber nicht sehr intuitiv, wenn man hier so und dort anders zählen muß. (im selben Compiler)

Das ist aber doch gerade dafür, daß man möglichst wenig an seinem alten Code ändern muss. Neuer Code kann ja den 0-basierten String-Helper verwenden und der alte Code die schon bisher vorhandenen Routinen. Nur bei direktem Zugriff auf einen Char über den Index muss man halt aufpassen - oder gleich die StringHelper Chars verwenden, das ist immer 0-basiert.

Man versucht doch wirklich es dir leicht zu machen :)

[himitsu]

Möglichst wenig?
Wenn man S[i] und Insert/Copy im Code hat, dann darf braucht man jetzt nur bei der Hälfte was ändern.
Beides in einer Schleife und man hat seinen Spaß.

Wenn Beides geändert wurden wäre, dann hätte nur die Schleife/Position geändert werden müssen.

Solange man nur für eine Plattform entwikelt, fällt es kaum auf, aber Multiplattform. :thumb:



Menno, jetzt hab ich Code drin, der wie Folgt aussieht. :wall:

Früher so

Delphi-Quellcode:

for i := Length(Data) downto 1 do
  case Data[i] of
    '"', '\', '/': Insert('\', Data, i);

Jetzt erstmal so (damit es erstmal richtig läuft)

Delphi-Quellcode:

for i := High(Data) downto Low(Data) do
  case Data[i] of
    '"', '\', '/': Insert('\', Data, i + 1 - Low(string));

oder ich mach das daraus

Delphi-Quellcode:

for i := Length(Data) - 1 downto 0 do
  case Data[i + Low(string)] of
    '"', '\', '/': Insert('\', Data, i + 1);

oder ich steig doch um

Delphi-Quellcode:

for i := Length(Data) - 1 downto 0 do
  case Data.Chars[i] of //case Data[i + Low(string)] of
    '"', '\', '/': Data.Insert(i, '\'); // Parameter umzudrehen ist auch eine geile Angelegenheit ... zum Glück knallt es hier, nicht wie bei Pos und ContainsStr

So, daß heißt also, daß es jetzt 3 4 Systeme gibt?
Außer bei den Helpern muß man also höllisch aufpassen und wird quasi liebevoll in die Helper gedrängt.

• Früher gab es nur die 1-Indizes
• Gedachte hatte ich, daß es nun im NextGen 0-indiziert ist und ich nur entcheiden muß, ob 0 oder 1, bzw. NextGen oder nicht.
  Und das es zusätzlich noch die neuen Helper mit immer 0 gibt.
• Und in Wirklichkeit gibt es nun "immer 0", "immer 1" und "manchmal so oder so" (je nach Compiler) :wall:
• [add]
  Delphi-Quellcode:

  {$ZEROBASEDSTRINGS OFF}

  :stupid:

[himitsu]

Ich könnte doch bestimmt auch den leicht versteckten Compilerschalter suchen und den Index wieder auf eins umschalten. :stupid:
Aber nein, so weit geh ich dann doch nicht. (Lösung 4)
[add]

Delphi-Quellcode:

{$ZEROBASEDSTRINGS OFF}

[edit] Ich schau gleich mal, was bei

Delphi-Quellcode:

{$ZEROBASEDSTRINGS ON}

im Windows-Compiler passiert. (Lösung 5)

[edit2] Char-Helper und {$ZEROBASEDSTRINGS} stammen doch aus XE3? Hmmm, wenn sich noch eine "ordentliche" Lösung

Delphi-Quellcode:

Char IN [...]

findet, dann könnte man sich fast einfach mal überlegen einfach XE3 als Minimum-Support festzulegen. :stupid:



Wenn man nun für NextGen kompiliert, fällt auch gleich auf, daß die Sache mit dem CharInSet auch schonwieder anders ist.
Wobei CharInSet intern komischer Weise genau das Selbe gemacht hat, wie das, was man damit ersetzen sollte.
Jetzt soll man den Char-Helper benutzen, aber ich glaub ich bin zu blöd ... ich finde dort keinen Ersatz dafür. :shock: (nein IsInArray ist keine Lösung)

Meine Lösungen ist

Delphi-Quellcode:

if Ord(P^) in [Ord('a')..Ord('z'), Ord('A')..Ord('Z'), Ord('_')] then ...

. Es funktioniert ganz genauso und bringt keine nervige Meldung.
Oder ich benutze

Delphi-Quellcode:

case P^ of 'a'..'z', 'A'..'Z', '_': ...; end;

.

[himitsu]

Ich hatte mich fast schon damit abgefunden und die Mindestversion beinah auf XE3 festgelegt.
War schon dabei einige Funktionen auf die neuen Helper umzuschreiben, aber da gibt es ein paar Probleme.

Man sollte besser nicht in die Helper schauen, was die für Mist bauen.

• Fast alles arbeitet mit Index 0,
• bis auf
  Delphi-Quellcode:

  S.Chars[i]

  , denn das arbeitet mit 1 oder 0, genauso wie
  Delphi-Quellcode:

  S[i]

  . :wall:
  
  Delphi-Quellcode:

  function TStringHelper.GetChars(Index: Integer): Char;
  begin
    Result := Self[Index];
  end;

• Man denkt dort gibt es "optimierte" Stringfunktionen, aber Chars werden erst nach String umgewandelt und arbeiten dann doch wieder mit den alten Funktionen.
  Ein Replace mit Char->Char könnte so wunderschön implementiert sein.
• Alles leitet nur auf die alten Funktionen um, dabei ergäbe es andersrum optimaleren/kürzeren Code.
• An vielen Stellen fehlt ein
  Delphi-Quellcode:

  inline;

  und man bekommt teilweise Results, bzw. zusätzliche temporäre Variablen, die bissl was Anderes machen, als man denken könnte.
  
  Delphi-Quellcode:

  S.Insert(3, 'xx');  // geht
  S.Insert(3, 'xx').Insert(7, 'zz');  // geht nur halb
  S := S.Insert(3, 'xx').Insert(7, 'zz');  // geht, aber kopiert sinnlos umher
  Insert(S, 'xx', 3);  Insert(S, 'zz', 7);  // macht genau das, was es soll

• Wieso ist Format nur als Class-Funktion deklariert?
  
  Delphi-Quellcode:

  S := '%d';  ShowMessage(S.Format([123]));

  könnte nett sein.
• Warum um Himmels Willen zeigt die Codevervollständigung nicht an, was Class-Function ist und was nicht?
• Und natürlich das Problem mit den mehreren Class-Helpern an einem Typ, was ja immernoch nicht funktioniert.
  Anhang 42854

Das heißt also QCs schreiben und hoffen es ist irgendwann wirklich mal "verständlich" nutzbar.

[Daniel]

Zitat:

Zitat von himitsu (Beitrag 1296268)

bis auf

Delphi-Quellcode:

S.Chars[i]

, denn das arbeitet mit 1 oder 0, genauso wie

Delphi-Quellcode:

S[i]

. :wall:

Delphi-Quellcode:

function TStringHelper.GetChars(Index: Integer): Char;
begin
  Result := Self[Index];
end;

Hast Du das mal ausprobiert? Bei mir arbeitet das /immer/ 0-basiert, da der gesamte Code des String-Helpers von der Compiler-Direktive $ZEROBASEDSTRINGS eingeschlossen ist.


Deinen Wunsch nach optimierten Strang-Funktionen kann ich zwar verstehen, aber das ist nur ein Helper, keine neue Strang-Bibliothek. Der Helper kapselt nur aufrufe, die sonst etwas mehr oder weniger umständliche wären.

[himitsu]

Ja, hatte es ausprobiert, aber war wohl scheinbar ein anderes Problem.

Der Versuch das über die History zurückzusetzen und nochmal hinzubekommen schlug Fehl.
Auch in einem Testprojekt kann ich es noch nicht reproduzieren.

Hätte die IDE wohl besser nicht zwischenzeitlich neu starten sollen.

Delphi-Quellcode:

{$STACKFRAMES OFF}
{$TYPEDADDRESS OFF}
{$WEAKLINKRTTI ON}
{$RTTI EXPLICIT METHODS([vcPublished]) PROPERTIES([vcPublished,vcPublic]) FIELDS([])}

{$ZEROBASEDSTRINGS ON}

function TestA(const S: string; i: Integer): Char; inline;  // praktisch TStringHelper.GetChars
begin
  Result := S[i];
end;

{$ZEROBASEDSTRINGS OFF}

function TestB({const} S: string; i: Integer): Char; inline;
begin
  //Result := S.Chars[(i - 5) div 2];
  Result := TestA(S, (i - 5) div 2);
end;

{$IFDEF NEXTGEN}
  {$ZEROBASEDSTRINGS ON}
{$ENDIF}

procedure TForm3.FormCreate(Sender: TObject);
var
  S: string;
  i: Integer;
  C: Char;
begin
  S := '12345';
  i := 5;
  C := TestB(S, 3 * 2 + {i}5);
  if S[3 + Low(string)] = C then
    Beep;
end;

[Bernhard Geyer]

Zitat:

Zitat von himitsu (Beitrag 1296268)

Delphi-Quellcode:

S.Insert(3, 'xx').Insert(7, 'zz');  // geht nur halb

Es geht wie es soll.
Insert liefert eine Referenz auf den geänderten String zurück. Diesen änderst du wieder. Der ursprüngliche String in S darf natürlich nicht geändert werden sondern es muss eine Kopie angelegt werden welche die Änderung beinhaltet. Würde der Ursprüngliche Wert mit dem zweiten .Insert geändert, wäre das ein Fehler.

Richtig wäre zu schreiben:

Delphi-Quellcode:

S.Insert(3, 'xx')
S.Insert(7, 'zz');