Größe von generischen Typen?

[himitsu]

Alao, wein Windows sind ja diese Typen an die Prozessorarchitektur angepasst.

Bei 32-Bit sind das z.B.:
INT = 4 Byte
BOOL = 4 Byte

Nur Delphi geht da einen anderen Weg:
Integer/Cardinal... sind zwar auch 4 Byte groß, aber Boolean will da nicht mitmachen ... der ist seit Anfang an immer nur 1 Byte (in D1, D4, D5 und D7 getestet)


Meine Compiler-Versions-Kontolle kann zwar diese Werte richtig auslesen, aber ich würde gern mal wissen, ob das nur bei Delphi so ist.
(Sowas ist z.B. wichtig, wenn man mit der WinAPI, oder ähnlichem arbeiten will, da es dort stimmt es ja "immer")

Also was machen da die anderen Compiler C und seine verschiedenen Varianten, besondes interessieren mich die anderen PascalCompiler FreePascal, Lazarus (oder wie der heißt) ...
vorallem, wie ist das bei Delphi.net ... haben die da dieses "Problem" schon behoben?

Also die Punkte vorwiegend interessieren mich demnach die Punkte "System Information" und "Size of..." in der Demo.


PS: wer noch was zu den Versionen und deren Erkennung, der anderen Pascal-Compiler sagen kann ... über PN würde ich mich freuen ... ansonsten könnte diese Datei auch bald mal in die CodeLib ... unter OpenSource kommt die ja eh bald mit dem Rest nach draußen ^^

[Oxmyx]

In C/C++ ist der native Typ "bool" auch nur 1 Byte groß. Der 4 Byte große Typ "BOOL" ist einfach nur als "int" definiert.
Unter Delphi gibt es auch einen 4 Byte großen Bool, nämlich LongBool.

[mirage228]

Hi,

hier mal die Werte für Delphi 2005.Win32 und .NET (falls es für Dich interessant ist)

Win32:

Zitat:

MS Windows
Borland Delphi
Compiler v9
Compiler_1_up Compiler_2_up Compiler_3_up Compiler_35_up Compiler_4_up Compiler_5_up Compiler_6_up Compiler_7_up Compiler_8_up Compiler_9_up
Compiler_9_down
Borland Delphi 2005
Delphi_1_up Delphi_2_up Delphi_3_up Delphi_4_up Delphi_5_up Delphi_6_up Delphi_7_up Delphi_8_up Delphi_9_up
Delphi_9_down
32 Bit
_IF_ CustomVariants DefaultParams Deprecated DynamicArrays Extsym Int64 Interface Library Message Nodefine Overload PerdefSet Platform ResString WideString
RTLConsts StrUtils Types Variants
CompilerVersion=17 RTLVersion=17
Boolean=1 Integer=4 Real=8 Char=1

und .NET:

Zitat:

MS Windows
Borland Delphi .Net
Compiler v9.net
Compiler_8Net_up Compiler_9Net_up
Compiler_9Net_down
Borland Delphi 2005 .Net
Delphi_8Net_up Delphi_9Net_up
Delphi_9Net_down
32 Bit .Net
_IF_ CustomVariants DefaultParams Deprecated DynamicArrays Extsym Int64 Interface Library Message Nodefine Overload PerdefSet Platform ResString WideString
RTLConsts StrUtils Types Variants
CompilerVersion=17 RTLVersion=17
Boolean=1 Integer=4 Real=8 Char=1 Char=2

Das einzige was mir aufgefallen ist, dass jeweils "Up" und "Down" der aktuellen Version gesetzt sind - das kann ja irgendwie net sein

mfG
mirage228

[himitsu]

ByteBool, WordBool, LongBool und LargeBool ... ist alles schon bekannt, mir geht es nur um die Gennerischen Typen, da bei diesen ja die Größe variieren kann und es auch abundzu tut (siehe Delphi 1)

Aber wie gesagt, diese kleine .inc kann das ja erkennen und ich kannkönnte demnach auch entsprechend Handeln, aber ich möchte halt gerne mal wissen, wie das anderswo auch noch aussieht.

Und natürlich könnte ich LongBool verwenden, aber bei 16-Bit müßte man ja WordBool und bei dem (vermutlich bald kommenden) 64-Bit benötogt man demnach LargeBool, damit alles seine Richtigkeit hat.


Und dass es bei C/C++ inen Unterschied zwischen bool und BOOL gibt wußte ich ja auch noch nicht ... also jetzt schon mal was gelernt ^^



Ich könnte ja morgen mal den ersten Teil meiner UCC hochladen, da ist eine Datei mit 'ner Zusammenstellung und Definition vieler Datentypen dabei

[add]
@mirage228
Ist doch richtig so, denn in der Datei Steht ja, dass
DELPHI_9 für "Borland Delphi 2005",
DELPHI_9_up für "Borland Delphi 2005 und höher"
und DELPHI_9_down für "Borland Delphi 2005 und niedriger" steht ^^

[NicoDE]

Zitat von himitsu:

mir geht es nur um die Gennerischen Typen, da bei diesen ja die Größe variieren kann und es auch abundzu tut (siehe Delphi 1)

Es könnte passieren, dass Integer und Cardinal unter Win64 32-Bit bleiben...
Zu dem 'Problem' mit boolschen Typen: In den Windows-Headern gibt es noch BOOLEAN.

Allgemein ist es dank fehlendem Präprozessor schwierig, in Delphi Language C-Typen in einem Quelltext ohne IFs abzubilden (und mitunter sehr aufwendig).

[himitsu]

Also eigentlich müßte sich das ändern, da ja die Pointer auch nur als
Type Pointer = Type Integer; definiert sind und im 64-Bit-System ja die Pointer auch 64-Bit sind - sonst könnte man ja die 2GB-Grenze nicht durchbrechen.
Außerdem sind diese Typen ja angeblich auf den Prozessor angepasst ... von der Geschwindigkeit her und so...


Das mit den IFs ... ich hoffe ich liege jetzt nicht neben dem "Thema", aber notfalls könnte man ja sich entsprechende generische Typen selbst erstellen

Irgendwo zentral einfach

Delphi-Quellcode:

Type genInteger = {$IFDEF 16_BIT} SmallInt {$ENDIF}
                  {$IFDEF 32_BIT} LongInt {$ENDIF}
                  {$IFDEF 64_BIT} LargeInt {$ENDIF};

[NicoDE]

Zitat von himitsu:

Also eigentlich müßte sich das ändern, da ja die Pointer auch nur als
Type Pointer = Type Integer; definiert sind und im 64-Bit-System ja die Pointer auch 64-Bit sind

Ist ohnehin rein theoretisch, da ich nicht erwarte, dass es plötzlich eine dcc64.exe gibt
Bei Microsoft bleibt der integrierte Typ 'int' bei 32-Bit, allerdings würde ich (rein theoretisch) davon ausgehen, dass ein Borland-Integer unter Win64 auch 64-Bit groß ist.

Zitat von himitsu:

Irgendwo zentral einfach

Das mit dem 'einfach' ist so eine Sache... Ich schreibe öfter Quellcode mit privaten System-Units. Zum Beispiel sind dort Handles (wie in C) als Pointer definiert (wegen x64-Version von FPC). Wenn ich nun meinen Quellcode einem Delphi-Entwickler geben will, dann muss ich andauernd hin- und zurück-casten...
...bin nicht sicher, ob ich damit nicht zuweit vom eigentlichen Thema abkomme. Ich wollte eigentlich nur darauf hinweisen, dass Portierung von Delphi-Quellen enorme Probleme aufwerfen kann.

Gruß Nico

[himitsu]

Zitat von NicoDE:

Ist ohnehin rein theoretisch, da ich nicht erwarte, dass es plötzlich eine dcc64.exe gibt
Bei Microsoft bleibt der integrierte Typ 'int' bei 32-Bit, allerdings würde ich (rein theoretisch) davon ausgehen, dass ein Borland-Integer unter Win64 auch 64-Bit groß ist.

Also wenn Boland da mithalten will, dann sollte mal bald soeine auftauchen -.-''

Zitat von NicoDE:

Das mit dem 'einfach' ist so eine Sache... Ich schreibe öfter Quellcode mit privaten System-Units. Zum Beispiel sind dort Handles (wie in C) als Pointer definiert (wegen x64-Version von FPC). Wenn ich nun meinen Quellcode einem Delphi-Entwickler geben will, dann muss ich andauernd hin- und zurück-casten...
...bin nicht sicher, ob ich damit nicht zuweit vom eigentlichen Thema abkomme. Ich wollte eigentlich nur darauf hinweisen, dass Portierung von Delphi-Quellen enorme Probleme aufwerfen kann.

Aus solchen Gründen, erstelle ich mir ja derzeit endlich mal ein zentrales Grundsystem, welches ich dann überall verwenden will ... theoretisch brauchte ich dann immer nur die "wenigen" Dateien zu ändern, oder halt nur die richtige/passende Version davon zu verwenden. (wobei einige der Dateien selber entscheiden sollen, was beim gerade verwendetem Compiler das "Beste" ist)

Darum hab ich ja auch solche Fragen, wie diese gestellt ... ich weiß ja nicht alles und irgenwie müßte ich ja dafür wissen, was wie arbeitet...

[NicoDE]

Zitat von himitsu:

Also wenn Boland da mithalten will, dann sollte mal bald soeine auftauchen -.-''

Die Diskussion ist nicht neu: QC#7324.

Zitat von himitsu:

Aus solchen Gründen, erstelle ich mir ja derzeit endlich mal ein zentrales Grundsystem, welches ich dann überall verwenden will ...

Ich meinte das Problem, welches dann auftaucht, wenn ich einem anderen Delphi-Entwickler eine hilfreiche Unit aber nicht meine WinAPI/WinDKK-Units geben will (gibt tausende Gründe dafür).

[himitsu]

Achso ... na ja, ich erstelle meine (größtenteils) als OpenSource ... hat auch sine Gründe ... vorallem, damit auch Verbesserungen durch andere mit einfließen können.