TRUE/FALSE Part

[Popov]

Delphi-Quellcode:

  ShowMessage('True = ' + BoolToStr(True));
  ShowMessage('False = ' + BoolToStr(False));

[Daniel]

Wir haben hier viele gute und sachliche Argumente gehört - aber lasst doch die Erbsenzählerei sein.
Nicht jedes Wort gehört auf die Goldwaage.

[BadenPower]

Zitat von Popov:

Delphi-Quellcode:

  ShowMessage('True = ' + BoolToStr(True));
  ShowMessage('False = ' + BoolToStr(False));

BoolToStr gibt ja auch nur die Strings zurück, welche in der Funktion hinterlegt sind

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;

Setzt man als 2. Parameter true kommt für
True nicht "-1" sondern "True"
und für False nicht "0" sondern "False"
zurück.

[himitsu]

Zitat von BadenPower:

Zitat von EWeiss:

Solange ich in Delphi arbeite ist True = 1

True war noch niemals 1.

Seit ich mit Delphi und dies ist schon seit Version 1, arbeite war True immer True.

Einfach einmal testen:

Doch.
ShowMessage(IntToStr(Ord(True)));
Deine Argumentation ist halt falsch, auch wenn sie zur Hälfte betrachtet (nur von außen und nicht von innen) schon richtig aussehen mag.

Es hat niemand gesagt, daß True = 1 ist, so wie du es versuchst zu erklären.

Genauso kann ich keine Char oder Pointer mit einem Integer vergleichen.
Willst du also auch behaupten, daß ein Zeilenumbruch nicht 10 und/oder 13 ist?

Rate mal, warum ich in meinem Beispiel den nummerischen ordinalen Wert in einen Boolean gecastet hatte, anstatt Ihn einfach so zu versuchen zuzuweisen.
Boolean ist intern ein Byte, aber wie dieses Byte behandelt und ausgewertet wird, hängt vom Typ ab. (Byte, ShortInt, AnsiChar, Enum, Set usw.)

[BadenPower]

Im Zitat von EWeiss steht:

Zitat:

True = 1

und dies ist eben nicht richtig, denn laut Delphi, nachzulesen unter "Boolesche Typen" ist True eben nicht 1 sondern:

Zitat:

Ord(True) = 1

Und dies ist ein gewaltiger Unterschied, den ich mit einfachen Mittel belegt habe, in dem ich einfach einen Integerwert 1 in der If-Bedingung verwendet habe.

Klar, dass dies nicht funktionieren kann, aber es sollte eben verdeutlichen, dass True eben nicht 1 ist.

Bei anderen Boolschen Typen also nicht Boolean sondern ByteBool, WordBool oder LongBool ist Ord(True) auch nicht 1 sondern ungleich 0.

[Caps]

Sorry,

in meinem abendlichen Schnupfen- und Erkältungswahn muss ich auch noch meinen Senf dazugeben:
Ich habe mich mit diesem Thema auch schon mal herumgeärgert.

Meines Erachtens ist die Definition der Konstanten True und False schlicht kontraintuitiv, da man in der Aussagenlogik keinerlei Probleme mit einem Vergleich (x = True) hätte.
Ich möchte mich nicht zu weit aus dem Fenster lehnen, aber True bedeutet in der natürlichen Sprache nunmal "wahr" und False bedeutet "falsch", und dann war ja da noch dieser Hinweis "benenne Deine Objekte und Variablen (und Konstanten) so, dass man die Bedeutung leicht erkennen kann".

Aber wie gesagt: Schnupfen und Erkältung - nichts für ungut

lg Caps

Edit:

In schwach typisierten Sprachen wie PHP ist es manchmal tatsächlich notwendig, direkt auf den Wahrheitswert zu prüfen, allerdings deshalb, weil man implizit den Typ mit überprüft:

Code:

if (x === true) { ... }

[Bernhard Geyer]

Zitat von mkinzler:

False ist als 0 deklariert -> True ungleich 0.
Delphi verwendet hierfür 1, C ( also auch WinaAPI) -1 ( als binäres Komplement zu 0)
1 ist aber <> -1 -< True ist nicht gleich True.

Eigentlich dachte ich das in C die Definition von

Code:

FALSE = 0;
TRUE = !FALSE;

ist.
Auch wenn man (jedenfalls vor Zig Jahren auch in jeder zweiten .h-Unit auch ein TRUE = 1 (oder = -1) sieht1

[BadenPower]

Zitat von EWeiss:

Sorry bestimmt schon oft besprochen..
Aber destotrotz!

Warum sollte man tunlichst auf das prüfen von True und False verzichten.
Kosmetisches Problem oder was steckt da hinter?

If Foo = True then if Foo then
If Foo = False then if not Foo then Was macht jetzt den Unterschied ?

Wenn Du auf If Foo = True then prüfst, dann prüft Du, ob Foo den Booleanwert TRUE hat.

Wenn Du If Foo then auswertest, dann prüft Du, ob die Auswertung von Foo "Wahr" ergibt.


Und tunlichst darauf verzichten halte ich für falsch, denn es gibt Situationen, in denen man direkt auf TRUE prüfen muss.

[Der schöne Günther]

Zitat von BadenPower:

Und tunlichst darauf verzichten halte ich für falsch, denn es gibt Situationen, in denen man direkt auf TRUE prüfen muss.

Elaborieren Sie.

[BadenPower]

Zitat von Der schöne Günther:

Zitat von BadenPower:

Und tunlichst darauf verzichten halte ich für falsch, denn es gibt Situationen, in denen man direkt auf TRUE prüfen muss.

Elaborieren Sie.

Ganz einfach:

1 ist halt nicht TRUE.

Aber 1 und TRUE ergeben beide WAHR.


Einfach einmal eine Form mit 3Buttons anlegen und testen:

Delphi-Quellcode:

unit Unit1;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls;

type
  TForm1 = class(TForm)
    Button1: TButton;
    Button2: TButton;
    Button3: TButton;
    procedure Button1Click(Sender: TObject);
    procedure Button2Click(Sender: TObject);
    procedure Button3Click(Sender: TObject);
  private
    { Private-Deklarationen }
   FVar: Variant;
  public
    { Public-Deklarationen }
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

procedure TForm1.Button1Click(Sender: TObject);
begin

  if (FVar = true) then
   begin
    ShowMessage('True');
   end;
  if (FVar = 1) then
   begin
    ShowMessage('1');
   end;
  if (FVar) then
   begin
    ShowMessage('nur FVar');
   end;

end;

procedure TForm1.Button2Click(Sender: TObject);
begin
  FVar := true;
end;

procedure TForm1.Button3Click(Sender: TObject);
begin
  FVar := 1;
end;

end.