@gammatester: OK, dann isses eben seit D2 so.
Den Teil hab ich wohl in der D5 Hilfe überlesen...und damals war die noch wirklich ausführlich.
Einige Auszüge aus der
OH meines Delphi 4 ... nur damit keiner behaupten kann, er wußte von nichts.
Zitat von
Reelle Typen:
Der generische Typ Real ist in der aktuellen Implementation mit dem Typ Double identisch.
Zitat von
Integer-Typen:
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 zugrundeliegende CPU und das Betriebssystem gewährleisten
Zitat von
String-Typen:
Das reservierte Wort string funktioniert wie ein generischer Typbezeichner.
Zitat von
Hansa:
Was predigst Du ? Bzw. wo , wie was ?
Ich sage jedenfalls : integer oder sonstwas hat 4 Byte. Basta. Auch unter Win128. Dann können sie ruhig kommen mit Bigint, SuperBigInt etc.
Zitat von
himitsu:
Na das mit dem Integer und den sich "ändernden" Typen.
Mavarik: Wenn deine Records (welche gespeichert oder übertragen werden) nur native Typen (LongInt statt Integer, LongWord statt Cardinal, Double statt Real und AnsiChar/WideChar statt Char) verwenden und auch noch "packed" sind, bzw. wenn eine bestimmte Ausrichtung explizit vorgegeben ist, dann gibt es keine Probleme, selbst wenn sich der Integer ändert oder nicht oder wenn nun
Unicode verwendet wird.
Innerhalb der Anwengung ist es nähmlich sehr gut, denn so würde mit dem Umstieg auf
Unicode oder eben 64 Bit (falls sich der Integer doch noch ändert) automatisch umgestellt.
Wenn es aber darum geht Daten an andere Programme zu übergeben, wozu auch die Speicherung zählt, wenn sich zwischendurch mal die Struktur des Programmes ändern kann, bis dieses dann wieder ausgelesen wird,
dann sollte man eben nur fundamentale Typen verwenden, da diese gleich bleiben, auch wenn sich die Programmstruktur ändert.
.........
Die generischen (veränderlichen) Typen wurden mal eingeführt, da sie sich an das Betriebssystem, bzw an den Compiler für dieses System anpassen und dort die "optimalen" Typen nutzen, welche nativ vom System unterstützt werden.
In Unicodesystemen (eigentlich seit
WinNT) ist die
API nunmal nativ
Unicode, also sind in einem Compiler dafür natürlich die Stantardtypen auch auf
Unicode eingestellt.
> Char=WideChar PChar=PWideChar und String=(WideString)UnicodeString
Unter einem 16 Bit Windows ist der Integer halt 16 Bit, bei einem 32 Bit Windows eben 32 Bit und für ein 64-Bit-System wäre dieser nunmal 64 Bit. (entsprechend den Registergrößen der CPU)
Daß Delphi leider immer "etwas" hinterherhinkt, ist leider eine blöde Tatsache ... also weswegen sich leider alle so an die zu lange "statisch" erscheinenden 32 Bit und
Ansi gewöhnen konnten.
(Mit Win2000 ist Windows seit dem Jahr 2000 im Konsumerbereich
Unicode und Delphi schaffte erst 2008, mit Delphi 2009, den Sprung.
Windows und die CPUs sind auch schon seit vielen Jahren 64 Bit und Delphi hat auch das noch nicht geschaft.
OK, XP64 kann man vergessen, aber seit Vista im Jahre 2007 hält nun auch immer mehr 64 Bit im Konsumerbereich einzug und Delphi hat es wiedermal immernoch nicht hinbekommen. (wenn ich das jetzt hochrechne, dann komm ich für den 64-Bit-Delphi-Compiler auf das Jahr 2015-2017)
(weil ich grad so schön am schreiben war ... hier nochmal für die Anderen)
In einigen Spielekonsolen sind wir schon seit Jahren über die 64 Bit hinaus, also könnte/wird dieses bestimmt auch irgendwann in den PCs Einzug halten.
Wenn die PCs dann mal 128/256 Bit haben werden (PS: Die Grafikkarten machen das doch anscheinend schon, und immer mehr Programmierer verschieben schon einige Berechnungen in die GPU), dann wird Delphi hoffentlich auch schon ein Weilchen 64-Bittig sein.