Insert und NextGen

[himitsu]

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

[edit] Ich schau gleich mal, was bei {$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 Char IN [...] findet, dann könnte man sich fast einfach mal überlegen einfach XE3 als Minimum-Support festzulegen.



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. (nein IsInArray ist keine Lösung)

Meine Lösungen ist 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 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 S.Chars[i] , denn das arbeitet mit 1 oder 0, genauso wie S[i] .
  
  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 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?
  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.
  Unbenannt.png

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

[Daniel]

Zitat von himitsu:

bis auf S.Chars[i] , denn das arbeitet mit 1 oder 0, genauso wie S[i] .

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 von himitsu:

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');

[himitsu]

Zitat von Bernhard Geyer:

Richtig wäre zu schreiben:

Delphi-Quellcode:

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

Delphi-Quellcode:

S.Insert(...);  // richtig
S.Insert(...);

S := S.Insert(...);  // geht, aber bissl sinnlos
S := S.Insert(...);

S.Insert(...).Insert(...)  // niemals so


S.Remove(...);  // falsch
S.Remove(...);

S := S.Remove(...);  // richtig?
S := S.Remove(...);

S := S.Remove(...).Remove(...);  // das geht ebenfalls

Insert gibt eine Kopie des Strings zurück und wenn man den nochmal ändert, dann bleibt der eigentliche String unverändert.

Das zweite Insert geht dann ins Nichts, obwohl man es "optisch" benauso gemacht hat, wie beim ersten Mal.

Insert verändert zwar den String selber, aber man sollte sich nun sicherheitshalber dennoch angewöhnen das Result neu zuzuweisen.
Während Remove, was scheinbar dem Delete entspricht, nur das Result beeinflust, also wenn das nicht verwirrend ist?

Delphi-Quellcode:

var
  S, S2: string;
begin
  S := 'ace';
  S.Insert(1, 'b');
  S.Insert(3, 'd');
  ShowMessage(S);  // abcde

  S := 'ace';
  S.Insert(1, 'b').Insert(3, 'd');  // zweites Insert verläuft sich im Nirgendwo
  ShowMessage(S);  // abce !

  S := 'ace';
  S := S.Insert(1, 'b').Insert(3, 'd');  // S wurde geändert, in abce, und wurde dann vom Result überschrieben
  ShowMessage(S);  // abcde

  S := 'ace'.Insert(1, 'b').Insert(3, 'd');  // keine Problem, da nur Result benutzt und die Änderung an der Konstante ins Nix ging
  ShowMessage(S);  // abcde



  // Insert als Erstes verhält sich anders, wie nachfolgende Aufrufe

  S := 'ac';
  S.Insert(1, 'b');
  S2 := S.Remove(1, 1);
  ShowMessage(S + ' ' + S2);  // abc ac

  S := 'ac';
  S2 := S.Insert(1, 'b').Remove(1, 1);  // Insert ändert S und Result, Remove geht nur auf Result
  ShowMessage(S + ' ' + S2);  // abc ac

  S := 'abc';
  S.Remove(1, 1);  // Remove hat auf S keine Wirkung
  S2 := S.Insert(1, 'b');  // Insert ändert S und S2
  ShowMessage(S + ' ' + S2);  // abbc abbc

  S := 'abc';
  S2 := S.Remove(1, 1).Insert(1, 'b');   // Insert hat keine Wirkung auf S (und Remove auch nicht ... sieht aber so aus, als ging es)
  ShowMessage(S + ' ' + S2);  // abc abc
end;

Naja, die Helper können nett sein, aber für Insert, Delete, Length und vorallem SetLengeh kann man sich selber doch fast nur empfehlen beim Alten zu bleiben.
PS: AnsiString, UTF8String und dyn. Arrays fehlen noch ganz. Was soll's, AnsiStrings kann man bei Multiplatform eh vergessen. http://andy.jgknet.de/blog/2013/10/t...-byte-strings/






Keine Ahnung was mit dem 0-Index los war. Inzwischen scheint es zu laufen.