Genau um sowas, eine Datei die etwas größer ist, in TStrings
zu laden.
Also ein Zeilenweises array of String. Das sollte doch gehen?
Das tut es ja jetzt schon, wenn man es entsprechend lädt. Also nicht mit Zuweisung von Text, CommaText oder LoadFromFile bzw. LoadFromStream. Die würden in der Tat 64-Bit Strings erfordern.
Interessant ist die Frage, was passiert bei den Properties CommaText und Text, denn die sind String
.
Eben, das knallt dann halt. Das ist aber meiner Meinung nach durchaus OK. Es ist eigentlich nicht zu rechtfertigen, dass man, nur um solche Sonderfälle abzudecken, den ganzen Unterbau auf 64-Bit Verträglichkeit auslegt. Auch in 64-Bit sind die meisten TStrings Instanzen mit überschaubaren Inhalten versehen.
Aber wie Sebastian schon schreibt, spricht ja auch nichts dagegen eine Ableitung von TStringList zu schreiben, bei der die LoadFromStream/SaveToStream Implementierungen eben nicht über SetTextStr/GetTextStr laufen. Dann könnte man diese ja auch für größere Dateien verwenden.
Als Nebeneffekt würde auch der interne Buffer für das Encoding wegfallen. Da liegt nämlich auch noch ein Speicherfresser: Erst wird ein Buffer angelegt, der den kompletten Inhalt der Datei in den Speicher lädt. Dann wird daraus anhand des Encodings ein String gemacht, bevor dieser dann zeilenweise zerlegt in die interne Liste wandert. Das braucht dann temporär mal eben so etwa 5x soviel Speicher wie die Datei groß ist (danach dann 2x).
Wie man dann allerdings halbwegs performant mit so einer Monster-Stringliste umgehen soll steht auf einem anderen Blatt.