Delphi und 64-Bit Programme

[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 Sinspin:

Wen juckt das überhaupt wie der intern aufgebaut ist?

Da ist in der Tat was dran. Rein von der Speicherstruktur sehe ich da kein wirkliches Hindernis. Allerdings gibt es etliche Stellen im Source, bei denen implizit eine String-Länge und auch die Indizierung mit 32-Bit angenommen wird. Das ist ein nicht zu unterschätzender Aufwand, unweigerlich begleitet von potentiell signifikanten Fehlerquellen.

Übrigens ist WideString auch keine Alternative (eigentlich sogar ein Rückschritt), da das interne Datenformat auch hier 4 Bytes für die Länge reserviert - dummerweise diesmal in Bytes, so dass ein WideString nur halb so lang werden darf wie ein string.

[TigerLilly]

Hmm. Egal, ob ich Code für 64 Bit oder 32 Bit kompiliere, ich gehe davon aus, dass der Code - nur für sich genommen - funktioniert. Schnittstellen, Dateien etc sind außen vor, das ist bei UniCode ja auch so. Dass ich mir beim Compilieren für 64 Bit überlegen muss, ob mein Code per se funktioniert, ist nicht so toll. Woher weiß ich denn, was in der RTL nicht funktionieren würde?

[Uwe Raabe]

Zitat von TigerLilly:

Woher weiß ich denn, was in der RTL nicht funktionieren würde?

Wenn du dich hierauf beziehst:

Zitat von Uwe Raabe:

Das ist ein nicht zu unterschätzender Aufwand, unweigerlich begleitet von potentiell signifikanten Fehlerquellen.

dann betrifft dieser Aufwand natürlich Embarcadero, sollten sie irgendwann mal 64-Bit-Strings unterstützen wollen. Für den Anwender (also uns) sollte das weitestgehend transparent sein.

[jziersch]

Braucht man wirklich Strings mit Int64 Länge? Was soll das bringen.

Für grosse Daten gibts ja MemoryStreams - die haben auch nicht das Problem, dass zwischen irgendwelchen codepages hin und her gewandelt wird. Viele moderne Speicherformate verwenden nur 8 Bit, also RTF, XML, HTML ... da strings mit seinen WideChar zeichen auch nicht aussreicht alle Zeichen zu codieren. Die Speicherung solcher Daten in einen "string" fürhrt dann regelmässig zu 00nn00nn00nn00nn.

Dass ein Integer 32 bit hat, auch unter 64 bit war meiner Ansicht nach die genau richtige Entscheidung, da der Entwickler so explizit die Möglichkeit hat zu entscheiden, ob der große Typ erforderlich ist, oder nicht und "alte" Programme 1:1 laufen.

Wichtig ist es aber IntPtr zu verwenden für alle Integer die auch Speicheradressen sein können- typischerweise für die Übergabe an SendMessage u.ä.

[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