Sei X dein String, der zu füllen ist.
Delphi-Quellcode:
Var
CurrentCharCountInX : Integer;
Procedure InitializeX;
Begin
SetLength (X, 1024);
CurrentCharCountInX := 0
End;
Procedure EnsureProperLengthOfX (LengthOfStringToAdd : Integer);
Begin
If CurrentCharCountInX + LengthOfStringToAdd > Length (X) Then
SetLength (X, 2 * Length(X));
End;
Procedure AppendStringToX (Const aString : String);
Var
LengthOfString : Integer;
Begin
LengthOfString := Length(aString);
EnsureProperLengthOfX (LengthOfString);
Move (aString[1], X[CurrentCharCountInX + 1], LengthOfString);
Inc (CurrentCharCountInX , LengthOfString);
End;
Procedure FinalizeX;
Begin
SetLength (X, CurrentCharCountInX);
End;
// TODO: Gib X einen besseren Namen
(*
Aufruf:
InitializeX;
AppendStringToX (Str1);
...
AppendStringToX (StrN);
FinalizeX;
*)
Wesentlich besser sollte es, denke ich, nicht gehen. Vielleicht bringt das auch überhaupt nichts.
Natürlich kann/sollte man die generische Move-Routine durch einen Gewinner der FastCode-Challenge ersetzen. Auch ein 'Inline' sollte noch etwas bringen.
Aber im Wesen dürfte das nahe am Optimum sein. Aber wie Astat schon treffend anmerkte, braucht das im normalen Leben kein Schwein. Vor allen Dingen nicht, wenn der String anschließend als
SQL-Befehl an einen
SQL-Server geschickt wird. Ich vermute in diesem Fall den Performancebottleneck nämlich nicht beim Konkatenieren...
