Boolsche Datentypen, die mehr als 1 Byte belegen

[Matze]

Hallo,

ja, ich habe eine Frage zu den einfachen Datentypen LongBool, Bytebool und WordBool. Mir ist der Sinn dieser Datentypen nicht klar.

In Dietmars Tutorial steht dazu folgendes:

Zitat von Dietmar:

Bei einem normalen Boolean ist es so, daß "True" den Ordinalwert "1" hat. Bei ByteBool, WordBool und LongBool hat "True" normalerweise den Ordinalwert "-1".
Einige Windows-API-Aufrufe liefern ein Ergebnis vom Typ BOOL. Dabei gilt für den einen Fall "Ergebnis=0" und im anderen Fall "Ergebnis<>0". Ein Wert ungleich 0 muß aber nicht unbedingt 1 oder -1 sein! Das Ergebnis: die Variable ist bei <>0 möglicherweise weder true noch false!

In der Online Hilfe steht dazu:

Zitat von OH:

Es gibt vier vordefinierte Boolesche Typen: Boolean, ByteBool, WordBool und LongBool. In der Praxis wird in erster Linie der Typ Boolean verwendet. Die anderen Typen dienen der Kompatibilität zu anderen Sprachen und Betriebssystembibliotheken.

Eine Boolean-Variable belegt ebenso wie eine ByteBool-Variable ein Byte Speicherplatz. Eine WordBool-Variable belegt zwei (ein Word) und eine LongBool-Variable vier Bytes (zwei Word).

Einmal ganz konkret: Wofür benötigt man diese Datentypen?

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 von OH:

Die anderen Typen dienen der Kompatibilität zu anderen Sprachen und Betriebssystembibliotheken.

Ist mir unklar. Wieso gibt es generell andere boolsche Datentypen?

[Mystic]

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.

[Oxmyx]

Was Mystic gesagt hat stimmt natürlich, ich will nur noch einen Fehler korrigieren, den du zitiert hast:

Zitat:

Ein Wert ungleich 0 muß aber nicht unbedingt 1 oder -1 sein! Das Ergebnis: die Variable ist bei <>0 möglicherweise weder true noch false!

Das stimmt nicht, per Definition ist False = 0 und True <> 0. Eine LongBool-Variable, die den Ordinalwert 17 oder 48 oder 87263487 hat, ist genauso True wie eine LongBool-Variable, die den Wert -1 hat, und jede if-Anweisung wird 87263487 als True behandeln.

[Matze]

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 PostMessage gemerkt, dass es LongBool gibt, davor kannt eich es gar nicht.

@Oxmyx: Ok, dann müsste man das in dem Tutorial korrigieren. Ich werde es Dietmar melden.

[runger]

Hallo Oxmyx,

auch was du sagst ist nicht ganz richtig:

Zitat aus der Delphi-Hilfe:

Zitat:

Boolean
False < True
Ord(False) = 0
Ord(True) = 1
Succ(False) = True
Pred(True) = False

ByteBool, WordBool, LongBool
False <> True
Ord(False) = 0
Ord(True) <> 0
Succ(False) = True
Pred(False) = True

Rainer

[edit=alcaeus]quote-Tags repariert. Mfg, alcaeus[/edit]

[Der_Unwissende]

Zitat von Matze:

@Mystic: Achso, das hat Performancegründe, aber ganz klar ist es mir trptzdem nicht. Wieso ist das schneller, als beim normalen Boolean?

Auch wenn die Frage nicht an mich gerichtet ist beantworte ich die einfach mal. Der einfache Grund ist die Registerbreite deines Prozessors. Heutige Prozessoren sind in der Regel 32 Bitig, das heißt nichts anderes, als dass deine Register 4 Byte breit sind. Selbst bei den 64 Bitern wird häufig ein 32 Bit BS verwendet, läuft also letztlich auf's selbe hinaus.
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

[Vjay]

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.

[Matze]

Hallo

@Der_Unwissende: Herzlichen Dank, nun ist mir das klar, wunderschön erklärt.

[jbg]

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).

[jbg]

Zitat von runger:

auch was du sagst ist nicht ganz richtig:

Zitat aus der Delphi-Hilfe

Dein Zitat zeigt, was die Konstante "True" für einen Wert hat, aber nicht was True/Wahr ist.

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;