![]() |
Boolsche Datentypen, die mehr als 1 Byte belegen
Hallo,
ja, ich habe eine Frage zu den einfachen Datentypen LongBool, Bytebool und WordBool. Mir ist der Sinn dieser Datentypen nicht klar. In [user=Brüggendiek]Dietmars[/user] Tutorial steht dazu folgendes: Zitat:
Zitat:
Möchte ich Wahrheitswerte haben, reicht mir ein normaler Boolean, der mir true / false (0 / 1) bereitstellt, was 1 Byte Speicherplatz belegt. Wieso soll ich für einen Boolean dann 2 oder sogar stolze 4 Byte, also 4 mal so viel Speicherplatz, belegen lassen? Möchte ich andere Werte als true und false dann greife ich sicher nicht auf einen boolschen Datentyp zu, sondern nehme Byte oder ähnliches. Klärt mich bitte auf. Eigentlich gehört das ja zu den Delphi Grundlagen, nur konnte ich nirgendwo den Sinn und Zweck dieser Datentypen finden. Insbesondere das hier: Zitat:
|
Re: Boolsche Datentypen, die mehr als 1 Byte belegen
Fremde Bibliotheken verwenden evtl. 2- oder 4-Byte Booleans. Wenn du nur 1-Byte Booleans in Delphi verwenden könntest, würdest du diese Bibliotheken nicht verwenden können.
Ich könnte mir vorstellen, dass Booleans mit der prozessornativen Größe (16 Bit = 2 Byte; 32 Bit = 4 Byte) schneller verarbeitet werden können. |
Re: Boolsche Datentypen, die mehr als 1 Byte belegen
Was Mystic gesagt hat stimmt natürlich, ich will nur noch einen Fehler korrigieren, den du zitiert hast:
Zitat:
|
Re: Boolsche Datentypen, die mehr als 1 Byte belegen
Hallo,
@Mystic: Achso, das hat Performancegründe, aber ganz klar ist es mir trptzdem nicht. Wieso ist das schneller, als beim normalen Boolean? Ich habe gestern am Beispiel ![]() @Oxmyx: Ok, dann müsste man das in dem Tutorial korrigieren. Ich werde es Dietmar melden. |
Re: Boolsche Datentypen, die mehr als 1 Byte belegen
Hallo Oxmyx,
auch was du sagst ist nicht ganz richtig: Zitat aus der Delphi-Hilfe: Zitat:
[edit=alcaeus]quote-Tags repariert. Mfg, alcaeus[/edit] |
Re: Boolsche Datentypen, die mehr als 1 Byte belegen
Zitat:
Schnelleren Speicher als diese Register wirst du nirgends im Rechner finden, Operationen auf ihnen laufen mit vollem Systemtakt. Ein solches Register wird auch nicht in Einzelteilen betrachtet (die Möglichkeit gäbe es, aber eben nicht für alle Register). Deshalb musst du alle Werte die nur 1 oder 2 Byte belegen in so einem Register mit 0en auffüllen. Willst du prüfen ob ein Wert ungleich 0 ist, und du hast 100000000, dann wäre das als Byte zwar eine 0, aber die oberste 1 könnte noch in dem Register stehen und der Vergleich (32 Bit) würde sagen es ist ungleich 0. Dieses Auffüllen mit 0en ist also ein Schritt mehr (pro Zugriff), den du machen musst. Dies entfällt bei einem Longbool ganz einfach. Du wirst es häufiger in C/C++ Bibliotheken finden, dass deswegen Datentypen DoubleWord orientiert angelegt werden, halt auch das Bool (in C gilt soweit ich weiß <> 0 -> True, 0 False). Das ist auch schon alles. Natürlich kann man sich darüber streiten ab wann es Sinn macht, denn bei den meisten Programmen wird die IDLE-Zeit und der Zugriff auf langsameren Speicher eine Boolean vs. LongBool Variable übersteigen, aber genauso könnte man fragen ob 3 gesparte Byte das wirklich Wert sind. An sich wird natürlich in der heutigen Zeit (riesiger Speicher, hohe Abstraktionsebene) viel mehr Wert auf Performance gelegt als auf Speicherverbrauch (nicht überall, ist klar). Wenn du schon dabei bist, schau einfach mal bei Integer und Cardinal vorbei, die gibt es auch nicht nur so. Selber Grund, die sind immer optimal was die Performance angeht, denn sie entsprechen immer der Registerbreite (bzw. dem BS). Nur wenn du ein festgelegtes Protokoll hast, eine Bibliothek oder ähnliches, wo du weißt wie viel Byte ein Wert exakt belegt, verwendest du dann LongWord statt Cardinal (analog für alle anderen). Gruß Der Unwissende |
Re: Boolsche Datentypen, die mehr als 1 Byte belegen
Besser hätte es glaube ich niemand erklären können.
Wir sehen hier als ein Beispiel des immer selben Kampfes: Performance vs Größe. Man muß halt immer abwägen was einem wichtiger ist. In einer schnellen Schleife würde sich ein 4ByteBool besser machen, während wenn nur sehr selten auf etwas zugegriffen wird, spezielle Datentypen Vorteile haben. Nach diesem Prinzip verfahre ich eigentlich immer, nur man muß sich halt vor Augen halten wieviel RAM schon allein die VCL belegt und ob man dann noch 3 Bytes hier und da sparen sollte, halte ich für mehr als fraglich. |
Re: Boolsche Datentypen, die mehr als 1 Byte belegen
Hallo
@Der_Unwissende: Herzlichen Dank, nun ist mir das klar, wunderschön erklärt. :thumb: |
Re: Boolsche Datentypen, die mehr als 1 Byte belegen
Der_Unwissende hat nicht ganz recht.
Denn die vier Hauptarbeitsregister EAX, EBX, ECX und EDX lassen sich sehr wohl unterteilen in AX, BX, CX, DX und AH, AL, BH, BL, CH, CL, DH, DL. Und der Delphi-Compiler nutzt das bei Boolean aus. Somit besteht da kein Performencegewinn, wenn man LongBool einsetzt. Der LongBool entstammt mehr dem Problem der unterschiedlichen Programmiersprachen. Selbst der Speicherzugriff ist bei einem LongBool und einem ByteBool identisch. Er kann unter umständen aber auch für den ByteBool schneller sein, genau dann, wenn der LongBool nicht aligned ist, als zwischen einer 4-Byte Addressgrenze liegt, was aber heutzutage nicht mehr vorkommen sollte (außer man verwendet packed records). |
Re: Boolsche Datentypen, die mehr als 1 Byte belegen
Zitat:
Ein Beispiel:
Delphi-Quellcode:
var
b: Boolean; begin b := Boolean(2); if b = True then ShowMessage('Wird nicht passieren, da b mit Konstante True verglichen wird'); if b then ShowMessage('Passiert sehr wohl'); end; |
Alle Zeitangaben in WEZ +1. Es ist jetzt 08:20 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