@Dejan Vu
Der TE ist in #5 bereits auf eine Lösung gekommen. Warum du dem TE in #7 wieder eine 2. Variante von #5 presentierst wird, erschließt sich mir nicht. Er hat gefragt, ihm ist das Insert() als eigene Lösung zuzugestehen. Völlig in Ordnung, er lernt es ja gerade.
Mavarik hat ihm in #6 wohlwollend zeigen wollen, wie man das schneller machen... Warum? Nun ich würde davon ausgehen, das der TE eines schönen Tages Automatisierungen vornehmen müßte, wenn nicht mit dem Beispiel, dann an anderer Stelle und in anderer Variante. Nun neigt man dazu bereits vorhandenen Code wieder zu nutzen, da es ja schon wunderbar mit TForm1.leerzeichen(text:string) funktioniert hat.
Ich bin nicht der Meinung, daß hier irgendwer den TE verwirren wollte, sondern auf sein konkretes Bsp. bezogen, mögliche Varianten der Herangehensweisen aufzeigen wollte.
Mavarik's Version (gefixt) und die von Sir Rufo zeigen ihm nur, daß man eben die String-Copy Orgien, ab 'ne Iteration > 2 wirklich vermeiden sollte. Das lernt er aus den Benchmarks: Numbers are talking!
Der TE kann sich diverse Erkenntnisse an allen Nachfolgenden Bsp. aneigenen. Wie: benutze Pointer-Inkrementierungen oder den Index des Strings, kalkuliere und reserviere den Speicher nur !einmal! und schieb rüber, was du braucht, schreibe kleine Funktionen und lagere diese aus ..... zum Bespiel.
Durch Mavarik's "schneller" in #6 ist mir bei der Aufgabe sofort aufgefallen, das man seiner Version noch so einiges abringen könnte ->#7
Ein wiederholtes "da geht noch was" und in Fragestellung, ob mein größeres Code-Konstrukt etwas bessere und messbare Ergebnisse liefert -> Benchmarks. Irrglaube wer denkt, wenig Code bringt in jedem Falle viel Geschwindigkeit!
Wenn der TE eines Tages sportliche/variable/hochgeschwindigkeits Resultate liefern sollte ... jeder hier wollte ihm auf seine Art und Weise zeigen, wie es geht. Uns hat man es ja auch mal gezeigt, oder nicht? Du hast ihm wiederholt, wie man es als Anfänger machen darf und man es bei mehr Erfahrung nicht machen sollte, warum auch immer. Er kann mit den zusätzlichen Code-Bsp. machen, was er möchte. Ist es zu kompliziert, sollte er weitere Erfahrungen sammeln und vielleicht später darauf zurückgreifen.
Ich habe hierbei auch etwas gelernt:
Code:
if (Pointer(Result) = nil) or //result unassigned?
(PLongInt(NativeUInt(Result) - SizeOf(LongInt))^ <> SrcLen) {PStrRec.Len} or //length different?
(PLongInt(NativeUInt(Result) - (SizeOf(LongInt) shl 1))^ <> 1) {PStrRec.RefCnt} then //no unique string?
SetLength(Result,SrcLen+((SrcLen-1) shr 2));
Für hoch performante String functions war ich es gewohnt erst den String-Refcount und die Länge zu testen, bevor ich ein SetLength() calle. Die älteren
IDE's haben in jedem Falle einen neuen Unique-String erzeugt. Nun scheint mir das dieser Test schon implizit dem SetLength drin ist. Oder baut das der Compiler neuerdings direkt ein? Das war nicht immer so, und gilt herauszufinden, seit welcher Version sich Delphi so verhält. Klar ich spare den Call aber der Code wird unleserlich und für jemanden, der davon keine Ahnung hat, völlig banane.
@Mavarik
Ist der Test so in Ordnung für dich? Ergebnisse akzeptiert?