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:

Delphi-Quellcode:

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:

Delphi-Quellcode:

type
  Integer = type NativeInt;

:P

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

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:

Zitat von Panthrax

Wirklich. Was geht mich C an!?

Ganz deiner Meinung.

Zitat:

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:

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:

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:

Zitat von jbg

Zitat:

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:

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:

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ß? :zwinker:
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).

[alzaimar]

Und wer castet, ist selbst Schuld. Typecasting bedeutet immer eine implizite Kenntnis über den Compiler.
Plattformübergreifend und allgemeingültig zu programmieren bedeutet, diese manchmal Klimmzüge entweder zu vermeiden, oder wenigstens wohldefiniert auszulagern.

Wer das nicht gemacht hat, ist der Depp. Nicht der, der mit dem Standard mitgeht. Anstatt auf die Windowsprogrammierer zu schimpfen, die vor 15+x Jahren nicht in weiser Voraussicht daran gedacht haben, das jemals jemand mehr als 2Gig benötigt (die Spezis unter uns hätten natürlich dran gedacht, klar!), sollte man sich lieber selbstkritisch fragen, ob man nicht auch andere Codestellen datentypenunabhängig nachprogrammieren sollte.

Gerade die Pointerarithmetik ist doch ein Grund gewesen, die Programmiersprachen zu modernisieren. Man soll gefälligst -wo's geht- die Finger davon lassen. Und wenn ich eine Routine nochmals optimieren will bzw. muss, dann markiere ich sie entsprechend und nehme mir diesen Frickelcode zur Not vor.

Wer natürlich Pointer und PChar-Klimmzüge als wertvolle Beiträge zu stabilem und portablem Code ansieht... Tja, der hat eben Pech gehabt und muss Nachsitzen. :mrgreen:

im Ernst Jungs. :mrgreen: Sind wir nicht alle selbst Schuld an diesem Dilemma?

[himitsu]

Vorallem seit Delphi 2009 sollte es doch wohl klar sein, daß man bei seinen Definition aufpassen sollte.

Eigentlich hatte ich immer da wo möglich die "freien" Typen, wie Integer, Cardinal, String und PChar verwendet, wo sich alles automatisch an die CPU und den Compiler anpassen sollte.

Und da wo ich "feste" Typen benötige oder wo es nötig ist, da hab ich eben LongInt, LongWord, AnsiString, PAnsiChar und Co. verwendet.

Immerhinn sollte es doch so "laut bekannter Definition" der Typen ja auch zukunftssicher sein und gerade beim Integer würden so nun Bemühungen der letzen Jahre potentiel vernichtet, obwohl ich doch eigentlich zukunftsicherer sein wollte. :wall:

Mal ganz im Ernst: Mir doch egal was andere sagen, aber mir wäre es lieber und es währe auch gerechter, wenn die bestraft werden, welche nie hören wollten.
Also diejenigen welche Integer verwendet haben, obwohl sie zwingend Int32/LongInt benötigt hätten.


Nehmen wir mal mein himXML. Dieses läuft ohne große Änderungen unter D2006 bis D2010 und dabei werden nur Dinge Versionsabhängig abgestellt/zugeschaltet, welche in den Versionen nicht exisiteren oder anders laufen. Selbst in D7 läuft der Code weitesgehend.
Und theoretisch hätte der Code nichtmal bei der Umstellung auf 64 Bit Probleme gemacht, wenn der Integer/Cardinal mitwachsen würde. Nichtmal UCS4 wäre ein Problem geworden, wenn es dann irgendwann mal kommt.

[implementation]

Bin ganz alzaimar's Meinung. Nicht umsonst heißen solche Zeigeroperationen "unsicherer Code" und werden in Java und C# nur durch spezielle Compiler-/Precompiler-Optionen ermöglicht.

Zitat:

Zitat von Panthrax

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?

Java und C# erlauben solchen "unsicheren Code" standardmäßig gar nicht erst, siehe oben.
Und in C hat man sich da einfach schon dran gewöhnt.

Mich wundert vor allem, dass euch das ganze erst jetzt auffällt. Das war doch schon ziemlich lange absehbar - etwa seit es die ersten 64bit-C/C++/Java/C#/VB-Compiler gab. Schaut ihr denn nie über den Delphi-Tellerrand? Im FPC-x64 ist das auch längst so (wie lange gibt's den jetzt schon?).

[himitsu]

Zitat:

Zitat von implementation

Bin ganz alzaimar's Meinung. Nicht umsonst heißen solche Zeigeroperationen "unsicherer Code" und werden in Java und C# nur durch spezielle Compiler-/Precompiler-Optionen ermöglicht.

Das liegt aber auch an diesem komischen Speichermanager, welcher selber den Speicher verwalten will, anstatt es dem Programmier zu überlassen ... wenn ich nun einen Pointer auf etwas zeigen lasse und der Speichermanager davon nichts weiß, dann gibt er den Speicher frei und mein Pointer wäre "sinnlos", bzw. "unsicher".

Wer seinen Speicher ordentlich verwaltet, der baucht keinen kranken Garbage-Collector.
Ich will selbstbestimmen, was mein Programm macht und soein "Ding"ist nur was für Faule.


Der Rand meiner Schüssel ist zu hoch, drum seh ich sowas nicht.
- mit C hab ich nicht viel am Hut
- und Lazarus mag mich nicht, also beschäftige ich mich damit nicht weiter

[Namenloser]

Warum macht CodeGear/Embarcadero nicht einfach einen neuen Compilerschalter? Genau so hätte man es auch bei der Umstellung auf Unicode machen können und könnte dann sogar den gleichen Source Code für Ansi und Unicode kompilieren.

Wenn man sich mal C-Header ansieht findet man sowas zuhauf:

Delphi-Quellcode:

{$IFDEF WIN64}
type
  Integer = Int64;
{$ELSE}
type 
  Integer = Int32;
{$ENDIF}
{$IFDEF UNICODE}
type
  Char = WideChar;
{$ELSE}
type 
  Char = AnsiChar;
{$ENDIF}

Warum macht man es nicht auch unter Delphi so?

[mkinzler]

Beu der Unicode Einführung hat man bewusst darauf verzichtet, da der Umstieg sonst nie funktioniert hätte. Nur so konnte man 3rd-Party Hersteller (Jomponenten, Erweiterungen usw.) dazu zwingen und hat damit in Kauf genommen, dass manche die Entwicklung eingestellt haben.

[SirThornberry]

Weil das eben nicht geht. Viele Api-Funktionen wurden mit "Integer" übersetzt. Und nur weil man plötzlich einen anderen Compiler verwendet heißt es nicht das automatisch alle Api-Funktionen die vorher einen 32bit-Integer erwartet haben jetzt einen 64bit-Integer erwarten.

[himitsu]

Zitat:

Zitat von SirThornberry

Weil das eben nicht geht. Viele Api-Funktionen wurden mit "Integer" übersetzt. Und nur weil man plötzlich einen anderen Compiler verwendet heißt es nicht das automatisch alle Api-Funktionen die vorher einen 32bit-Integer erwartet haben jetzt einen 64bit-Integer erwarten.

Ja und, dann wird das einfach in den entdprechenden Headern der APIs mit angepaßt.
Wenn dort in Delphi ein LongInt statt einem Integer steht, dann paßt alles wieder. :roll:

[Medium]

Zitat:

Zitat von himitsu

dann gibt er den Speicher frei und mein Pointer wäre "sinnlos", bzw. "unsicher".

Nein, es heisst unsicher, weil man als Programmierer damit sehr leicht Dinge tun kann, die man so garnicht wollte. Mit dem GC hat das rein überhaupt nichts zu tun. Zudem gibt es in C# die Möglichkeit einen unsafe{..} Block zu deklarieren, in dem u.a. auch der Typ "IntPtr" verwendet werden kann, sowie Zeigerarithmetik wie von C gewohnt. Nachdem man unsafe Code in den Compileroptionen dann noch eingeschaltet hat, kann man fröhlich drauf los pointern - und man ist sich dann sicher, dass es nach quasi 2-maliger Bestätigung auch WIRKLICH so gewollt ist. Allerdings ist das als zeimlich üblber Stil anzusehen, ausser es geht um die Anbindung älterer APIs (wofür diese Option insbesondere geschaffen wurde).

Zitat:

Wer seinen Speicher ordentlich verwaltet, der baucht keinen kranken Garbage-Collector.
Ich will selbstbestimmen, was mein Programm macht und soein "Ding"ist nur was für Faule.

Dann verwende bitte auch keine case-Konstrukte, und diverse Schleifen. Sowas macht man doch bitte sehr schön von Hand mittels Labels und bedingter Sprünge!

Zitat:

Der Rand meiner Schüssel ist zu hoch, drum seh ich sowas nicht.

So viel ist hier denke ich mehr als klar geworden :(

[Namenloser]

Was wird jetzt eigentlich aus der Technik z.B. Objektreferenzen in der Tag-Eigenschaft von visuellen Komponenten zu speichern? :gruebel:

[himitsu]

Zitat:

Zitat von NamenLozer

Was wird jetzt eigentlich aus der Technik z.B. Objektreferenzen in der Tag-Eigenschaft von visuellen Komponenten zu speichern? :gruebel:

Das war's dann wohl damit, also wenn .Tag und andere Integer (in SendMessage z.B., wobei da ja eh LPARAM und WPARAM genommen werden sollten) weiter als Integer (32 Bit) vorhanden sind.

[Panthrax]

@Implementation, wenn ein 14jähriger diese Meinung vertritt, ist das so..., allerdings ist das Zitat aus dem Zusammenhang gerissen: Es geht nicht nur um Zeiger, wenn es um die 32- oder 64-Bit-Kompilate desselben Quelltextes geht. Sondern es geht darum, dass bspw. eine Integer-Variable das ist, weshalb sie als Integer-Variable deklariert wurde: "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." (Delphi-Hilfe)

Zeigeroperationen sind per se auch kein unsicherer Code. Der "Fachbegriff" "unsicherer Code" bezeichnet Code, dessen Speicherverwaltung sich der Müllabfuhr (aka "Garbage Collector") entzieht. Weil Delphi keine Müllabfuhr hat, könnte man auch Objekte dieser Kategorie zuordnen. Trotzdem werden sie verwendet, denn sie sind ein gutes, bewährtes Konzept. Genau so verhält es sich mit Zeigern.

@Alzaimar, bei Ihnen frage ich mich allerdings, ob Ihr Beitrag in Ihrem Kopf überhaupt die Moderatorenschleife durchlaufen hat!? Dass Sie das Thema nicht berührt, ist offensichtlich. Es war überflüssig, dass in einem solch feisten Beitrag zu verpacken. Im Übrigen verwendet die RTL und VCL ausgiebig den Typ Integer für Zeigerarithmetik. -- Wenn Sie die für "Frickelcode" halten? Entsprechend hohe Verbreitung hat dieses Vorgehen. Und ja, die notwendige Voraussicht, die gar nicht so weise hat sein müssen, hat man haben können. Nicht wenige haben diese auch gehabt! Zunächst war vorhersehbar, dass Speicher größer werden und Zeiger Adressen in diesem Speicher fassen können müssen. Und auch ganz praktisch sind die C-Leute schon einmal über ihre eigene Inkonsistenz gestolpert, so dass man hatte das Wort auf 2 Byte fixieren müssen. Die ursprüngliche Definition eines Wortes ist die volle Registerbreite, und ist damit das, was man in Delphi von Cardinal erwartet: Der mitwachsende, generische Datentyp. Bei der Umstellung von 16 auf 32 Bit wollte man dann aber nicht den vielen, tollen C-Quelltext ändern, und hat stattdessen das Doppelwort eingeführt. Daraus folgte wiederum, dass 16-Bit-Programme "16-Bit-Programme blieben". Delphi ist eine sehr typtreue Sprache, und es ist grotesk, wenn die wohldurchdachte Typensystematik durch externe Idiotie miniert wird.

@SirThornberry: Integer statt Cardinal zu verwenden, entstammt der Zeit, als es Cardinal noch nicht gab. Natürlich ist Cardinal semantisch besser.

An die Schnittstellen habe ich auch gedacht (*.h-Dateien, Dateiformate usw.). Meiner Ansicht nach ist es ein Fehler, etwa einen mitwachsenden Datentyp zu verwenden, wenn die Größe jedoch festgeschrieben ist. Entsprechend sollte man den Fehler korrigieren, und nicht zwangsweise den Quelltext anrühren, der zum Mitwachsen ausgelegt ist.

[mkinzler]

Ich finde auch das Integer mitwachsend bleiben sollte. Wer explizit 32Bit meint kann ja Cardinal verwenden.

[samso]

Soweit ich mich erinnere, soll die Tag-Eigenschaft auf 64 Bit erweitert werden (Delphi and the Integer data types).

SendMessage ist bei Win64 auf 64 Bit erweitert.

Zitat:

Einige Datentypen waren 32 Bit, jetzt 64 Bit
LRESULT, HANDLE, LPARAM, WPARAM, size_t, intptr_t, uintptr_t

aus
Portierung von 32Bit Applikationen auf 64Bit

[Panthrax]

Vielleicht noch einmal zum Versätndnis: Die Typen Integer (mit Vorzeichen) und Cardinal (ohne Vorzeichen) wurden bisher als mitwachsend propagiert. Wer feste größen benötigt kann ShortInt, SmallInt, LongInt, Word usw. verwenden.

Vom Hörensagen (Lesenschreiben :stupid: ) gibt es das Gerücht, dass Integer und Cardinal bei 32 Bit fixiert bleiben sollen.

[mkinzler]

Integer war bei TP und Delphi 1 16Bit. Cardinal war immer 32Bit

[Panthrax]

Das widerspricht sich ja nicht für die Zukunft mit der Delphi-Hilfe.

[mkinzler]

Allen Bauer hat allerdings für seine Pläne kräftig Gegenwind im CG Forum bekommen ud ich hoffe, das er sich diese Schnapsidee noch einmal überlegt

[Panthrax]

Schnapsidee, genau. Kann man den Gegenwind nachlesen? Ich habe schon ein bisschen quergelesen im Netz. Was ich so am Rande immer wieder über die C-Sachen mitbekomme, reicht auch von Verwirrung bis Widerspruch; selten, dass mal einer echte Zustimmung äußert.

[mkinzler]

Einen Link habe ich gerade nicht. Es gab aber den gesagten Thead im CG Forum, in dem der Zuspruch auch sehr gering war