Delphi und 64-Bit Programme

[jaenicke]

Zitat von hoika:

Hier müsste Embarcadero auch bei StringList nacharbeiten.

Andere mit 64Bit erzeugten Programme können das ja auch.

Die arbeiten dann aber auch nicht mit einer String-basierten Struktur wie einer TStringList. Denn auch z.B. in C# oder anderen .NET Sprachen können Strings nicht länger sein... das Limit ist ähnlich wie bei Delphi.

Wenn man geeignete Klassen wie eben einen Stream verwendet, kann man ja auch in Delphi problemlos mehrere GiB in den Speicher schaufeln.

[Sinspin]

Ich dachte das Integer der generische Typ ist und automatisch zu Int64 wird, wenn man auf 64Bit als Zielpattform übersetzt.
Früher war das jedenfalls mal so das aus 16 Bit Integer 32 Bit wurden beim Umstieg auf ein neueres Delphi (incl schöner Probleme beim lesen von Binärdateien, bei denen man keinen Gedanke auf das Anpassen des Loaders verschwendet hatte)

[TheDelphiCoder]

Das war wohl so beim Wechsel von Delphi 1 zu Delphi 2.
Integer bleibt aber tatsächlich bei 4 Byte. Wenn es automatisch gehen soll, dann brauchst NativeInt bzw. NativeUInt.

[dummzeuch]

Zitat von TheDelphiCoder:

Das war wohl so beim Wechsel von Delphi 1 zu Delphi 2.
Integer bleibt aber tatsächlich bei 4 Byte. Wenn es automatisch gehen soll, dann brauchst NativeInt bzw. NativeUInt.

Außer man verwendet (auch) noch ein älteres Delphi, bei dem NativeInt auch für 32 Bit Programme als 64 Bit deklariert ist. Das gilt für Delphi 7 bis 2007.

[hoika]

Hallo,
und ich bleibe dabei.
Ein TStringList sollte unter 64Bit mehr Daten verwalten können als unter 32Bit.

Auch Embarcadero bringt ja immer das "alter Code läuft wie bisher".
Ja, aber mit 64Bit muss auch der komplette 64Bit-Speicherbereich ausgenutzt werden!

Punkt!!!

Und jetzt macht mich rot

[jaenicke]

Zitat von hoika:

Ein TStringList sollte unter 64Bit mehr Daten verwalten können als unter 32Bit.

Dann würde mich interessieren wie du dir das konkret vorstellst? Sollen Strings deshalb eine andere interne Struktur bekommen?

[Sinspin]

Zitat von jaenicke:

Zitat von hoika:

Ein TStringList sollte unter 64Bit mehr Daten verwalten können als unter 32Bit.

Dann würde mich interessieren wie du dir das konkret vorstellst? Sollen Strings deshalb eine andere interne Struktur bekommen?

Ja, natürlich! Wen juckt das überhaupt wie der intern aufgebaut ist? Früher war es ein Byte am Anfang und maximal 255 Bytes dahinter.
Jetzt ist es was? ...und in Zukunft? Wollen wir ehwig gestrig bleiben? Rostig? Alt?

Der Typ String ist noch immer ein reserviertes Wort im Quelltext, also Compilermagic.
Dass man die realen String Typen vieleicht besser um eine 64Bit Variante erweitert, sollte klar sein.
Aber String ist jetzt schon dynamisch das was man eingestellt hat. Warum dann unter 64Bit nicht auch 64Bit tauglich?

Dass man beim übersetzen in 64Bit den Kopf angeschaltet lassen muss sollte jedem klar sein. Bestimmte Sachen, wie einen String in eine Binärdatei schreiben oder daraus lesen ohne eine Wrapper zu verwenden der sich um 32Bit / 64Bit unterschiede kümmert ist dann halt als Dummheit zu verbuchen.

[Uwe Raabe]

Zitat von hoika:

Ja, aber mit 64Bit muss auch der komplette 64Bit-Speicherbereich ausgenutzt werden!

Das fände ich jetzt aber sehr unfair gegenüber den anderen Anwendungen.

[Bernhard Geyer]

Zitat von Uwe Raabe:

Zitat von hoika:

Ja, aber mit 64Bit muss auch der komplette 64Bit-Speicherbereich ausgenutzt werden!

Das fände ich jetzt aber sehr unfair gegenüber den anderen Anwendungen.

[Stevie]

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.

Zitat von hoika:

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