![]() |
Keine richtige Frage zu DWord
Hallo
dies ist eine Sache die mir gerade durch den Kopf geht und ich poste sie hier, weil es ohne "vielleicht" Belang ist. Ich schreibe mir zu Zeit eine Komponente rum um das Bass Projekt. Zitat:
die man locker mit einem Byte, Word oder integer erledigen kann. Warum nehmen diese guten Programmierer :wink: so große Deklarationen |
AW: Keine richtige Frage zu DWord
Hmm.... ich könnte jetzt stumpf auf's Handbuch verweisen, aber ich versuch's mal kurz anzureißen:
Zuerst einmal: warum soll ein DWord/Cardinal größer sein als ein Integer? Ich gehe mal von Win32 aus, sind alle drei 4 Byte groß. Byte und Word auch :) Win32 ist ein 32 Bit Betriebssystem, das läuft auf einer 32 Bit CPU, da sind 32 Bit die "kleinste" Verarbeitungseinheit. Klar kann man innerhalb von 4 Bytes auch 4 einzelne Byte oder 2 einzelne Word unterbringen, das kostet aber Performance. |
AW: Keine richtige Frage zu DWord
Wobei die Performnancekosten relativ begrenzt sind, da es auch CPU-Befehle gibt, die jeweils auf der konkreten Größe arbeiten. Man kann ja z.B. bei einer 64-Bit CPU nicht nur z.B. RAX ansprechen (64 Bit), sondern auch EAX (32 Bit), AX (16 Bit) und AH / AL (8 Bit).
Schneller wird es aber mit den kleineren Datentypen sicher nicht. Zu DWord / Cardinal versus Integer: Integer ist ein Metadatentyp, der auf einen konkreten Datentyp gemappt ist, in dem Fall auf LongInt. Hierbei handelt es sich um einen vorzeichenbehafteten Datentypen. DWord bzw. Cardinal hingegen ist vorzeichenlos und kann daher größere Zahlen enthalten, da negative Zahlen darin nicht gespeichert werden können. |
AW: Keine richtige Frage zu DWord
CCRDude
Ja da hast Du recht, wie Dumm von mir Ich denke immer noch in 8 bit, aber richtig in einem 32 Bit System macht das keinen Sinn, Nun wird mir das auch mit LongBool klar. jaenicke Danke das ist sehr aufschlussreich. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 13:33 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz