Verständnisfrage Boolean <-> Zahl

[Der schöne Günther]

Ich weiß nicht, ob man noch alte Steintafeln ausgräbt auf denen das schon so geregelt war, aber ich kenne Boolean als Ganzzahl immer mit 0 für False und 1 für True .

Auch Delphis Boolean.ToInteger() gibt 0 oder 1 aus. Warum in aller Welt gibt BoolToStr(..) eigentlich '0' und '-1' aus? Weder ist das konsistent, noch kann ich mir irgendeinen Grund denken.

Delphi-Quellcode:

function BoolToStr(B: Boolean; UseBoolStrs: Boolean = False): string;
const
  cSimpleBoolStrs: array [boolean] of String = ('0', '-1');
begin
  if UseBoolStrs then
  begin
    VerifyBoolStrArray;
    if B then
      Result := TrueBoolStrs[0]
    else
      Result := FalseBoolStrs[0];
  end
  else
    Result := cSimpleBoolStrs[B];
end;

[Meflin]

... vielleicht, weil eine andere (gängige) Definition von Booleans ist, dass 0 = false und alles andere true ist?

[BUG]

Zitat von Meflin:

weil eine andere (gängige) Definition von Booleans ist, dass 0 = false und alles andere true ist

Frei aus der Hüfte geschossen, um zu erklären, wie man auf -1 kommen könnte:
Wenn man -1 als vorzeichenbehafteten Integer darstellt, sind alle Bitstellen auf 1 gesetzt. Was auch eine übliche Darstellung für true ist.

[Der schöne Günther]

Richtig! Diese Füchse! Für einen signed Datentyp ist -1 ja 0xFF..FF und 0 ist 0x00.00. Macht also doch durchaus Sinn.

Trotzdem: Das hätte ich bei einer ToInteger() -Methode verstanden, nicht bei einem ToString() !

[himitsu]

Jupp, also False = 0 und True <> 0.

Wobei die "Konstanten" da etwas anders sind, denn diese können nunmal nur einen Wert enthalten.
In Delphi ist die Konstante True als 1 ($01 = Byte) deklariert, während es in den C-Sprachen meistens als -1 ($FFFFFFFF) deklariert ist.

In C vermutlich, damit es mit dem AND sicher klappt, wenn man den "Boolean" als Integer interpretiert.


Wieso allerdings BoolToStr grade -1 nutzt, hab ich noch nie verstanden,
aber im Notfall kannst du einfach TrueBoolStrs anpassen und dort als Erstes die 1 einfügen.

IntToStr(Ord(B))

[Medium]

Der Hintergrund ist übrigens einfach der NOT-Operator. Binär gesehen dreht der ja einfach nur jedes Bit um. Und Prozessoren können einzelne Bits nicht so toll (bzw. überhaupt nicht) benutzen. Also hat man für einen Boolean meist mindestens ein Byte zu benutzen. Man kam daher zu dem Entschluss, dass "false" = 0 sein sollte, also 0b00000000. Dreht man nun jedes Bit davon durch NOT um, erhält man 0b11111111. Jetzt kommt es auf ein Mal darauf an, als was ich den Wert interpretiere: Byte oder SmallInt (signed byte)! "true" ist daher, im Falle von Byte als benutzte Datenstruktur, entweder -1 oder 255. Sicher ist nur, das "false"=0.

Delphi macht es hier ein wenig anders, weil man sich wohl dachte: "Jou. Das ist seltsam." Und man ging daher, und legte FALSE=0, und TRUE=1 fest, und machte den NOT-Operator so intelligent, dass er zwischen Binär-NOT und logischem NOT zu unterscheiden weiss. Man ist ja immerhin in einer typsicheren Sprache unterwegs, da kann man das hervorragend so tun. Wenn jedoch irgendwelche WinAPI-(C)-Gelöte beteiligt sind, wird klammheimlich - und das ist auch, warum es Types wie LongBool usw. gibt - konvertiert.

Letztlich kann man sich daher im Grunde nur auf eines wirklich verlassen: FALSE=0. Alles andere ist TRUE, egal was es nun genau ist.

[himitsu]

Genau deswegen macht man auch nicht if B = True then , denn hier wird nicht nach booleschen, sondern nach ordinalen Regeln verglichen.

Und ja, man kann daher wirklich dem Typ Boolean mehrere Werte zuweisen.

Delphi-Quellcode:

var
  B: Boolean;

B := Boolean(2);



if B then
  ShowMessage('Ja');

if not B then
  ShowMessage('Nein');

if B then
  ShowMessage('Ja')
else
  ShowMessage('Nein');

if B = True then 
  ShowMessage('Ja')
else if B = False then
  ShowMessage('Nein')
else
  ShowMessage('Vielleicht');  // :D

[Aphton]

Zitat von himitsu:

Delphi-Quellcode:

var
// ..
if B = True then 
  ShowMessage('Ja')
else if B = False then
  ShowMessage('Nein')
else
  ShowMessage('Vielleicht');  // :D

Und schon haben wir Fuzzylogik xD