Aufschrei: Longint soll voraussichtlich 64bit werden

[Bernhard Geyer]

Gehen wird mal auf Grundproblem zurück:

Wo sind Probleme zu erwarten wenn (der 64-Bit-Compiler?) longint als 64-Bit Integer definiert. Einfallen würden mir hier:

1, Verwendung von File of <Type> wenn z.B. in einem Record ein longint liegt.
Lösung: Umschreibung der Typdefinition des Records

2, Verwendung dieses Typs bei jedlicher Art von Senden von Daten zwischen Anwendungen/übers Netz wenn hier ebenfalls ein Typ mit einem longint vorliegt
Lösung: Ebenfalls die Definitionen anpassen.

3, Dynamische Dateierzeugung wenn mittels fester größenangabe geschrieben wurde.
Lösung: Anpassung der Load/Save-Routine.


Alle Rahmenanpassungen (z.B. Win64-API) sollte von Borland gemacht sein. Ist eigentlich der wParam und lParam ebenfalls angepaßt/auf 64-Bit gehoben worden?
Ist dieser Aufwand zu groß (für einen 64-Bit Port)?

@jbg: In welcher Newsgroup war der Post? War das der Komplette Post das longint 64-Bit werden wird?

[jbg]

Zitat:

Zitat von Bernhard Geyer

Ist dieser Aufwand zu groß (für einen 64-Bit Port)?

Das nicht, aber bis jetzt war der Longint im Vergleich zum Integer als sicherer 32Bit Datentyp vorhanden. Und jeder den Umzug von 16 Bit auf 32 Bit mitgemacht hatte, hat in seiner weiteren Programmentwicklung immer Longint statt Integer für die Datenpersistenz benutzt, weil er das Fiasko nicht wiederholen wollte.

Zitat:

@jbg: In welcher Newsgroup war der Post? War das der Komplette Post das longint 64-Bit werden wird?

Das ist tief im "Suggested Alternative Unicode Implementation (for Rudy+ misc others)" Thread versteckt. Allen Bauer hat aber heute Nacht (unserer Zeit) seine Aussagen als noch nicht definitiv zurückgezogen.

[mkinzler]

@jbg: Könntest du mal einen Link auf den Thread posten?

[Medium]

Das eigentliche Problem ist dabei doch eher philosophischer Natur. Weil anpassen kann man natürlich immer, es bedeutet allerdings gerade in größeren Projekten einen gewissen Aufwand, und eine nicht unerhebliche Quelle für sehr eklige Fehler.

Aber LongInt zu redefinieren ist, als wäre mein Word nun 4 Byte breit, oder nur 2 Byte, dafür aber mein Byte nun 16 Bit. LongInt gehört einfach zu den Datentypen, denen nicht nur Format, sondern auch Größe zugesichert sind, im Gegensatz z.B. zu Integer. Ich schreibe ja gerade dann "LongInt" statt "Integer" irgendwo hin, wenn ich genau weiss, dass die Größe des Typs relevant ist, und ich mich nicht auf den generischen Integer stützen kann. Die bloße Idee das zu ändern ist schon absurd.

[jbg]

Link zum Newsgroupthread

[Dezipaitor]

Dann hoffen wir mal, dass es zumindest einstellbar wird. Also ala {$DEFINE COMPILER_64} oder so.

[mkinzler]

Sonst schaufeln sie sich ihr eigenes Grab.

[mschaefer]

Moin, moin,

Vielleicht gibt es ja dann rückwärts einen int32 Typ.
Bin ehdem der Meinung, das Nummerieren der einleuchtendere Weg ist:

in16 int32 int 64 int256 int1024 | float32p32 float64p64

Grüße in die Runde ...

[mkinzler]

Das wäre unabhängig davon besser; das löst aber das Problem von Altcode usw. nicht.

[Dezipaitor]

Damals war der Umstieg von 16 auf 32bit auch nicht einfach. Das wird dieses Mal auch nicht so einfach gehen.