Aufschrei: Longint soll voraussichtlich 64bit werden

[jbg]

In den Newsgroups hat Allen Bauer (CodeGear) verlauten lassen, dass der Datentyp Longint möglicherweise auf 64Bit wachsen soll. Damit würde der als "sicher 32Bit" geltende Longint, der schon zu 16bit Zeiten 4 Bytes lang war, seine Größe ändern.

[mkinzler]

Daran haben sich c Jünfer schon längst gewöhnt, dass Typen wachsen. Besser wären aber Typen, welchen man die länge ansieht und die sich nicht ändern
BTW. Andersrum wäre es schlimmer :mrgreen:

[Bernhard Geyer]

Und wieso nimmt man nicht für 64-Bit Integer int64? Welche einfachere Portierung auf Win64 will man damit erreichen?

[Union]

Mir wäre ein FUNKTIONIERENDER uint64 wichtiger...

[Christian Seehase]

Zitat:

Zitat von jbg

In den Newsgroups hat Allen Bauer (CodeGear) verlauten lassen, dass der Datentyp Longint möglicherweise auf 64Bit wachsen soll.

Wozu soll dass den gut sein. :gruebel:
Für den 32-Bit Compiler gibt es schon int64, und für einen 64-Bit Compiler müsste integer erweitert werden, da der ja schliesslich als generischer Integer-Typ mit Vorzeichen definiert ist.

Zitat:

Zitat von Union

Mir wäre ein FUNKTIONIERENDER uint64 wichtiger...

:thumb:

[3_of_8]

Also dass man Integer und Cardinal auf 64-Bit Maschinen als 64-Bit Typen definiert, ist logisch. Die hatten ja schon immer Prozessorwortbreite, wenn ich mich recht entsinne. Aber LongInt? :shock:

Was ist mit Programmen, die sich darauf verlassen, das LongInt 4 Byte lang ist, wie es ja mehr oder weniger "versprochen" war? Die müsste man alle umschreiben.

[mirage228]

Ich könnte mir vorstellen, dass man dann dafür einen Compiler-Schalter bzw. eine Option wie bei string (AnsiString <> ShortString) macht...

mfG
mirage228

[Dezipaitor]

Tja, die Leute schreiben am lautesten, die nie sizeof(Longint) verwenden :D

[jbg]

Zitat:

Zitat von Dezipaitor

Tja, die Leute schreiben am lautesten, die nie sizeof(Longint) verwenden :D

Viel Spaß, wenn du Daten aus Dateien einliest, die mit der 32bit Version erstellt wurden.

[richard_boderich]

Mir wäre ein FUNKTIONIERENDER uint64 wichtiger...

Kann ich nur voll zustimmen!

mfG Richard

[3_of_8]

Zitat:

Zitat von Dezipaitor

Tja, die Leute schreiben am lautesten, die nie sizeof(Longint) verwenden :D

Soll ich dann auch SizeOf(Byte) schreiben, weil sich die Größe eines Bytes ja mal ändern könnte? Oder soll ich mir in jeder Unit Pi neu definieren, weil sich Pi ja mal ändern könnte?

[generic]

Ich verstehe die ganze Aufregung nicht.

Behauptungen:
1) Niemand schubst in modernen Anwendung noch Speicherbereiche per Hand durch die Gegend ?
2) Wenn eine Erweiterung auf 64 Bit gemacht wird, wird doch sicherlich die "least significant 32 bit" zuerst im Speicher kommen. Somit würden Zeiger nach wie vor auf den "richtigen" Bereich zeigen.
3) statische Records werden in OO-Anwendungen nicht genutzt.
4) Windows API Aufrufe werden in der Anwendung nicht direkt gemacht, sonder durch die RTL/VCL gekapselt. Diese wird von Codegear sicherlich angepasst.

[Medium]

Boa lebst du in einer Kunstwelt.

[igel457]

Zitat:

Zitat von generic

1) Niemand schubst in modernen Anwendung noch Speicherbereiche per Hand durch die Gegend ?

Ups.

[Luckie]

Zitat:

Zitat von generic

1) Niemand schubst in modernen Anwendung noch Speicherbereiche per Hand durch die Gegend ?

Und alle nicht modernen Anwendungen tritts du in die Tonne?

Zitat:

3) statische Records werden in OO-Anwendungen nicht genutzt.

So?

Zitat:

4) Windows API Aufrufe werden in der Anwendung nicht direkt gemacht, sonder durch die RTL/VCL gekapselt. Diese wird von Codegear sicherlich angepasst.

So? Und was, wenn ich, aus was für Gründen auch immer, auf die VCL verzichte?

[3_of_8]

Ein einfaches Beispiel ist das Laden eines 3D-Models, zum Beispiel. Da ist zum Beispiel im Dateiformat ein Block für ein Mesh definiert, bei dem am Anfang ein 4-Byte unsigned Integer mit der Anzahl der Dreiecke steht. Wenn man jetzt da mehrere solche Längenangaben per Array und Filestream laden will, kracht es, wenn ein Integer plötzlich 64 Bits und nicht mehr 32 hat.

[Medium]

Generic weigert sich bestimmt, alles zu lesen was nicht auf .xml endet :-D

[Bernhard Geyer]

Zitat:

Zitat von Medium

Generic weigert sich bestimmt, alles zu lesen was nicht auf .xml endet :-D

Wieso? Diverse 3D-Formate wie 3DXML, VRML, XVL basieren auf (komprimiertes) XML

[Medium]

Gut, dann benutzen wir ab sofort nur noch diese oder? Und für die ganzen "alten" (=gängigen und verbreiteten) schreiben wir schöne Konverter damit wir nicht alles neu modeln müssen, und werfen die Programme weg, die sie nicht verarbeiten können. Prima Lösung find ich!

[Elvis]

Zitat:

Zitat von Medium

Generic weigert sich bestimmt, alles zu lesen was nicht auf .xml endet :-D

Ich denke er meinte es sarkastisch, nur war es etwas unglücklich ausgedrückt. ;-)

btw, ICH weigere mich alles einzulesen, was kein XML ist. Und das meist auch noch in dritter Instanz.
Erst wenn es tatsächlich Sinn macht auf die Interop eines offenen nicht-binären Formates zu verzichten, würde ich überhaupt auf die Idee kommen, mir weitere Argumente für non-XML anzuhören...
Es gibt viel zu viele beschissene binären Formate auf dieser Kugel.
Und bei jeder einzelnen geht einfach sinnlos Zeit drauf um sie entweder nach exzessivem Docs-schmökern zu reimplementieren oder schlimmer: Man muss Reverse-Engineering walten lassen.

[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.

[Medium]

Man könnte sich es aber einfach machen ;) (zumindest in diesem Bezug). Eine Einführung einer neuen Nomenklatur, die wie mschaefer schrieb wäre durchaus eine Universallösung. Man darf halt nur nicht die alten Namen entfernen, sondern führt diese auf letztem Stand mit. Somit wäre auch dem Benutzer (=wir) sofort klar, ob er einen generischen oder statischen Typ vor sich hat: Ist eine Zahl im Namen, wird es ein statischer sein.

[generic]

Weitsichtigkeit wird belohnt. Wenn ihr nun eure Projekte umstellt, denkte bitte an die 128bit Prozessoren ;-)

[Elvis]

Zitat:

Zitat von jbg

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.

Ich würde keine einzige seiner Aussagen als definitiv ansehen. Der ist mir viel zu sehr ein Politiker, als dass ich ihm mehr glauben würde als unbedingt notwendig.

Aber es war anscheinend sehr gut ihm sofort Kritik um die Ohren zu wehen.
Ich bezweifle, dass sie LongInt jetzt noch hochskalieren können. :-)