Integer und Cardinal bei 32 Bit eingefroren? NativeInt?

**Panthrax**

In älteren Quelltexten finde ich regelmäßig Zeigerarithmetik:

Delphi-Quellcode:

			var

  Ptr: Pointer;

begin

  Inc(Integer(Ptr));

end;

Da für den Typ Pointer die Zeigerarithmetik nicht definiert ist, hat man sich in der Vergangenheit oft mit dem Typ Integer beholfen. Das funktioniert aber nur wenn SizeOf(Integer) = SizeOf(Pointer). Um darauf nicht angewiesen zu sein, stelle ich bei mir um, und verwende den Typ PByte, für den die Zeigerarithmetik definiert ist:Inc(PByte(Ptr)); Schaut man mal in die RTL oder VCL, wird dort mit den Typen Pointer und Integer freigiebig umgegangen. Vom Hörensagen her, wird der Typ Integer (und Cardinal?) 32 Bit lang bleiben (

z.B. hier angesprochen). Das widerspricht in meinen Augen der

Hilfe zu "einfachen Typen":

Zitat:

Es gibt zwei generische Integer-Typen: Integer und Cardinal. Diese Typen sollten, wenn möglich, immer verwendet werden, da sie die optimale Ausführungsgeschwindigkeit für die zugrunde liegende CPU und das Betriebssystem gewährleisten.

Wird auch Cardinal bei 32 Bit eingefroren?
Weiß vielleicht jemand, wo man etwas gegen diesen Blödsinn tun kann, Integer bei 32 Bit einzufrieren?

Ich denke an 32- oder 64-Bit-Programme vom selben Quelltext. Was nutzt ein 64-Bit-Kompiler, wenn die Datentypen nicht mitwachsen? Soll dann etwa überall auf NativeInt umgestellt werden!? Ich habe eigentlich noch genug von der Zwangsumstellung der Standardimplementierung von String und Char als Unicode. Wenigstens würde im Falle von Integer das hier gehen: Wenn die anderen nicht wollen, dass Integer mitwächst, ich will:

markieren

Delphi-Quellcode:

			type

  Integer = type NativeInt;

**himitsu**

Das Problem ist, daß es in C (und auch von Microsoft in dessen Win-API-Headern) so gelöst wurde, daß INT aka Integer unter 64 Bit nicht angepaßt wurde und nun hat wohl Emba vor dieses genauso zu übernehmen.

Wobei ich der Meinung bin, daß man doch nicht unbedingt jeden "Scheiß" mitmachen muß.

**Panthrax**

Zitat von himitsu:

Das Problem ist, daß es in C (...)
Wobei ich der Meinung bin, daß man doch nicht unbedingt jeden "Scheiß" mitmachen muß.

Wirklich. Was geht mich C an!? Wenn die schon das Problem erzeugen, wie lösen die es denn!?

**himitsu**

Zitat von Panthrax:

Wirklich. Was geht mich C an!?

Ganz deiner Meinung.

Zitat von Panthrax:

wie lösen die es denn!?

Da gibt es wohl einen "speziellen" Integertypen, welcher so groß wie ein Pointer ist.

**jbg**

Zitat von Panthrax:

Was geht mich C an!?

Es ist nicht nur in C so. Auch Java und C# machen das so.

Zitat:

Wenn die schon das Problem erzeugen, wie lösen die es denn!?

Wer? Microsoft oder Embarcadero? Und welches Problem?

Zitat:

Wird auch Cardinal bei 32 Bit eingefroren?

Voraussichtlich ja.

Zitat:

Weiß vielleicht jemand, wo man etwas gegen diesen Blödsinn tun kann, Integer bei 32 Bit einzufrieren?

15+x Jahre in die Vergangenheit reisen und den Windows-Programmierern sagen, dass sie statt INT und LONG lieber INT32 und INT32 benutzen sollen.

**himitsu**

Zitat von jbg:

15+x Jahre in die Vergangenheit reisen und den Windows-Programmierern sagen, dass sie statt INT und LONG lieber INT32 und INT32 benutzen sollen.

Ja und, wenn sie nun ihre Programme auf 64-Bit portieren wollen, dann können sie das jetzt immernoch ändern.
Warum soll man dann die Definition von Typen nun ändern, nur weil Manche nicht hören können?
Integer = hieß nunmal "CPU-Registerbreite" (welche der Compiler unterstützt) und nicht "32 Bit".

Ist doch praktisch genauso wie der Scheiß, den Codegear mit Delphi 2009 verbrockt hat.

AnsiUpperCase ist standardmäßig Unicode, obwohl es Ansi heißt.
Und das nur weil man den Umstieg vereinfachen will, aber beim Neuprogrammieren ist es ein totaler Schwachsinn.
Genauso wie die interne Codepageprüfung bei den Strings (seit D2009)

**Panthrax**

Zitat von jbg:

Zitat von Panthrax:

Was geht mich C an!?

Es ist nicht nur in C so. Auch Java und C# machen das so.

Und wenn alle anderen aus dem Fenster springen...

Zitat von jbg:

Zitat:

Wenn die schon das Problem erzeugen, wie lösen die es denn!?

Wer? Microsoft oder Embarcadero? Und welches Problem?

Das ist "ein Problem", welches eigentlich keins sein sollte. Ich sehe diese Wolken am Horizont:

Der vorhandene Quelltext mit Zeigerarithmethik muss geändert werden, wenn Pointer mitwächst, Integer aber nicht: Inc(Integer(Ptr));. Besonders hier sehe ich viel Spaß, denn der Kompiler sagt erstmal nichts dazu, und wenn die oberen 32 Bit des Zeigers unterschlagen werden, kommt es vielleicht nicht einmal immer zum Fehler. Wer nicht weiß, wonach er sucht, wird hier echt viel Zeit lassen, da es auch aus Gewohnheit so leicht zu übersehen ist.

Wenn dann einmal ein 64-Bit-Kompiler verfügbar wird, erzeugt dieser doch nur Mogelpackungen, wenn das Programm keine 64-Bit-Datentypen verwendet, obwohl es das könnte. Was soll werden, wenn es einmal 128-Bit-Prozessoren gibt? -- Nur mal so gesponnen.

Zu guter letzt, welches Vertrauen kann man noch entgegenbringen, wenn man sich nicht einmal auf solch fundamentale Aussagen verlassen kann!?

Java und C# sind sicherlich nicht der beste Vergleich, wenn es um Zeiger geht. Aber wie machen es denn C, Java und C#, wenn es darum geht aus einem Quelltext eine 32- und eine 64-Bit-Anwendung zu erstellen? Wie stellt man sich das vor, wenn sich die Registerbreite ändert: gleicher Quelltext anderes System?

Zitat von jbg:

Zitat:

Weiß vielleicht jemand, wo man etwas gegen diesen Blödsinn tun kann, Integer bei 32 Bit einzufrieren?

15+x Jahre in die Vergangenheit reisen und den Windows-Programmierern sagen, dass sie statt INT und LONG lieber INT32 und INT32 benutzen sollen.

Ich habe es befürchtet...

Trotzdem, was soll das!? Jetzt muss die Delphigemeinde ausbaden, was C-Idioten verplant haben!? Sollen die doch ihre Datentypen ändern! -- Was geht mich C an!?

**SirThornberry**

Mich wunder das einigen einen Pointer jemals auf Integer gecastet haben. Ein Pointer konnte doch noch nie negative Werte annehmen weswegen ich immer auf Cardinal gecastet habe (und das aufgrund des Hinweises der Hilfe das Cardinal, Integer etc. mitwachsen werden).
Ich finde es ebenfalls Schwachsinn das man die Größen jetzt einfrieren will nur weil einige die sich nicht an die Gegebenheiten gehalten haben jetzt Probleme bekommen.

**himitsu**

Wenn Integer eingefroren wird, dann wird es wohl auch der Cardinal, da es ja die selben "Typengrößen" sind, nur mit dem Unterschied des Vorzeichens.

Also wirst du auch mit Cardinal Probleme bekommen.

PS: Rate mal, warum es standardmäßig bei den Speichermanagern eine 2 GB-Grenze gibt und man sein Programm erst auf die 4 GB (3,x GB) freischalten muß?

Weil Viele "Integer(P) < 0" als Fehlerkennzeichnung oder "Integer(P) <= 0" für leere/ungültige Zeiger verwendet haben.

Wenn nur Integer, aber nicht Cardinal eingefroren würde, dann wäre das meines Erachtens nach noch viel Schlimmer.

**SirThornberry**

Ich wollte nicht ausdrücken das es mich nicht stört sofern cardinal bleibt sondern ich wollte 2 Botschaften in einem Post unterbringen. Zum einen das ich immer Cardinal verwendet habe und nie auf die Idee gekommen wäre Integer zu verwenden um einen Pointer zu casten. Und zum anderen die Informationen das da wohl etwas schief läuft wenn man Integer, cardinal etc. einfriert (also alles wovon es vorher hieß das es nicht eingefroren wird).