Wer ne 32GB Datei in eine TStringList läd, hat ganz andere Probleme als den Fakt, dass es bei mehr als (2^31)-1 Zeilen kracht.
Ein TStringList sollte unter 64Bit mehr Daten verwalten können als unter 32Bit.
Tut sie auch - eine 32bit Anwendung kann ohne large address aware 2GB Speicher verwalten, mit 3GB (32bit
OS) bzw 4GB (64bit
OS).
Wer sich mal die Mühe gemacht hat, in den Code von TStringList zu schauen, der wird gesehen haben, dass pro Eintrag 8 bzw 16 byte benötigt werden (TStringItemList).
D.h. dass selbst beim Eintragen von Leerstrings in eine TStringList bei einer non LAA Anwendung gerade mal Speicher für ca 268mio Einträge zur Verfügung steht.
Anders herum betrachtet heißt das, dass eine TStringList mit einer Capacity von MaxInt als 64bit Anwendung schon allein ca 32GB verbrauchen würde (MaxInt*16)! Und da sind noch gar keine Strings drin.
Mal kurz durchgerechnet, welche Mindestzeilenlänge die Datei haben müsste, wenn sie in UTF8 kodiert wäre und nur
ASCII Chars enthalten würde - das wären 32GB Zeichen. Eine TStringList hat maximal Platz für 2^31-1 Einträge.
Somit müssten die Zeilen im Durchschnitt 16 Zeichen lang sein, das kommt mir doch schon sehr kurz vor für eine Datei, die man mit einer TStringList verarbeiten möchte.
Ich stand kürzlich selbst vor der Entscheidung, ob ich bei den Spring Collections auf NativeInt für Index umstellen soll oder nicht, aber da kommt man dann doch auf ganz andere Probleme, wie den Fakt, dass ein open Array auch unter 64bit seinen versteckten High Parameter nur als Int32 übergibt.
P.S. Ist auch schon eine ganze Weile lang "bekannt" (vermutlich inzwischen schon wieder vergessen worden, ist halt nicht einfach bei zig Tausend Issues in nem JIRA den Überblick zu behalten, woll)
https://quality.embarcadero.com/browse/RSP-12438