TRUE/FALSE Part

[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?

Delphi-Quellcode:

If Foo = True then

Delphi-Quellcode:

if Foo then

Delphi-Quellcode:

If Foo = False then

Delphi-Quellcode:

if not Foo then

Was macht jetzt den Unterschied ?

gruss

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

[Dalai]

Detaillierte Erklärung hier: Über den Umgang mit Boolean.

MfG Dalai

[BadenPower]

Zitat:

Zitat von EWeiss (Beitrag 1295382)

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?

Delphi-Quellcode:

If Foo = True then

Delphi-Quellcode:

if Foo then

Delphi-Quellcode:

If Foo = False then

Delphi-Quellcode:

if not Foo then

Was macht jetzt den Unterschied ?

Wenn Du auf

Delphi-Quellcode:

If Foo = True then

prüfst, dann prüft Du, ob Foo den Booleanwert TRUE hat.

Wenn Du

Delphi-Quellcode:

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:

Zitat von BadenPower (Beitrag 1295389)

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

Elaborieren Sie.

[EWeiss]

Zitat:

Zitat von mkinzler (Beitrag 1295386)

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.

Nun mir erschließt sich das immer noch nicht.
Solange ich in Delphi arbeite ist True = 1

Was spricht also gegen die Prüfung von
if Foo = True then
welchen zustand kann ich denn solange ich in Delphi unterwegs bin noch erreichen als 1

Würde ich innerhalb Delphi mit mehreren API's unterwegs sein also bsp. C++.dll könnte ich verstehen das hier eventuell inkonsistenten entstehen.
Aber so?

Doch kosmetische Sache?

gruss

[himitsu]

Ein Delphi-Boolean ist intern als ein Byte (1 Byte) deklariert, denn die kleinste "adressierbare" Speicherheinheit ist nunmal ein Byte.
Der BOOL in C++ ist intern als ein INT (Integer, 4 Byte) deklariert.

Die Boolean-Variablen haben also nicht zwei Zustände, sondern 256.
Einer davon ist False, da das immer 0 ist.
"Wahr" ist dagegen als ungleich 0, bzw. "nicht Falsch" definiert.

Die Konstante "True" ist in Delphi aber als 1 deklariert. (kann halt nur einen Wert besitzen)

Delphi-Quellcode:

var
  B: Boolean;

B := True;
if B then Beep;
if not B then Beep;
if B = True then Beep;  // hast du ein Glück gehabt, daß es "zufällig" genau 1 ist
if B = False then Beep;

B := Boolean(2);
if B then Beep;
if not B then Beep;
if B = True then Beep;  // nänänänänäääääääää
if B = False then Beep;
if B <> False then Beep;

Du kannst niemals sagen, ob der Wert nicht doch aus irgendeiner API kommt, ober über Assembler oder sonstwelche bösen Casts erzeugt wurde.
Darum einfach grundsätzlich niemals genau auf True prüfen, außer mann will/muß eben wissen, ob es wirklich genau die True-Konstante ist.

Ja, ich hab in Boolean auch schonmal absichtlich mehr als nur einen Wert kodiert (ThreeState)
oder bei einem Enum oder Set "ungültige" Werte benutzt. :angle2:

Und ich kenne viele WinAPIs, die in Delphi falsche implementiert sind.
BOOL statt INT und anderesrum.

[Dalai]

Zitat:

Zitat von EWeiss (Beitrag 1295391)

Doch kosmetische Sache?

Nein. Sobald du eine API-Funktion direkt aufrufst, die z.B. einen BOOL zurückgibt (oder einen solchen Typ als out-Parameter hat), entspricht das Ergebnis eben nicht mehr zwingend einem Boolean. Dazu muss man noch nicht einmal irgendeine DLL laden, denn auch kernel32.dll, shell32.dll usw. reichen da bereits aus.

EDIT: Hier mal ein Beispiel für eine Datenstruktur mit einem BOOL in der WinAPI: http://blog.delphi-jedi.net/2008/09/...n-and-integer/

MfG Dalai

[stahli]

Aber selbst die "kosmetische Sache" würde mich überzeugen:

Delphi-Quellcode:

if (EtwasZutrifft) then TuEtwas;

ist doch eigentlich eingängig.

Delphi-Quellcode:

if (EtwasZutrifft = WahrIst) then TuEtwas;

ist eher sperrig zu lesen.

Wenn es dann noch Compilerbedingte Gründe für die verkürzte Schreibweise gibt, würde ich mich auf jeden Fall für diese entscheiden.


Nachtrag:
Mir fiel jetzt noch ein:

Delphi-Quellcode:

if (A = B) = True then ...

würde ja auch niemand schreiben.

[Sir Rufo]

Zitat:

Zitat von stahli (Beitrag 1295405)

Aber selbst die "kosmetische Sache" würde mich überzeugen:

Delphi-Quellcode:

if (EtwasZutrifft) then TuEtwas;

ist doch eigentlich eingängig.

Delphi-Quellcode:

if (EtwasZutrifft = WahrIst) then TuEtwas;

ist eher sperrig zu lesen.

Wenn es dann noch Compilerbedingte Gründe für die verkürzte Schreibweise gibt, würde ich mich auf jeden Fall für diese entscheiden.

Mit englischen Begriffen liest es sich sogar fast wie Prosa

Delphi-Quellcode:

if APerson.IsMarried then
  APerson.DriveHome
else
  APerson.StayWhereYouWant;

[Popov]

Zitat:

Zitat von EWeiss (Beitrag 1295391)

Nun mir erschließt sich das immer noch nicht.
Solange ich in Delphi arbeite ist True = 1

Was spricht also gegen die Prüfung von
if Foo = True then
welchen zustand kann ich denn solange ich in Delphi unterwegs bin noch erreichen als 1

Ich mag keine Dogmen. Das mit dem

Delphi-Quellcode:

if Foo = True then

Bann ist in etwa wie der Tipp der Mutti: Kind, es ist gerade der schönste Sonnenschein draußen, aber nimm trotzdem den Regenschirm mit, es könnte ja regnen.

Solange man NUR Pascal programmiert und keiner witzig ist und etwas manipuliert, sollte es keine Probleme geben.

Aber Boolean ist meiner Kenntnis nach mindestens ein Byte, so dass da mehr als nur zwei Zustände reinpassen. Und man weiß ja nie mit wem man kommuniziert und was der für True hält, z. B. 1 oder -1 oder 25.

[BadenPower]

Zitat:

Zitat von Der schöne Günther (Beitrag 1295390)

Zitat:

Zitat von BadenPower (Beitrag 1295389)

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.

[BadenPower]

Zitat:

Zitat von EWeiss (Beitrag 1295391)

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:

Delphi-Quellcode:

Const
  Pruefen = 1;

procedure TForm1.Button1Click(Sender: TObject);
begin

  if (Pruefen) then
   begin
    ShowMessage('Hier komm ich niemals hin, da dieser Code nicht kompiliert wird');
   end;
end;

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

[EWeiss]

Zitat:

Zitat von Daniel (Beitrag 1295418)

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.

Jo und ich denke es wurde alles gesagt was meine Frage bzgl. Kosmetik angeht..
Danke für die rege Beteiligung.

gruss

[Bernhard Geyer]

Zitat:

Zitat von mkinzler (Beitrag 1295386)

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:

Zitat von Popov (Beitrag 1295416)

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:

Zitat von BadenPower (Beitrag 1295415)

Zitat:

Zitat von EWeiss (Beitrag 1295391)

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.

Delphi-Quellcode:

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. :zwinker:

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? :zwinker:

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

[EWeiss]

Zitat:

Zitat von BadenPower (Beitrag 1295435)

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.

Wie Daniel schon sagte..

Zitat:

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.

Ich dachte das jeder versteht was damit gemeint war. (Ohne Erbsen zu zählen)
Programmiere nicht erst seit gestern und wollte nur wissen ob die Art ob man auf True vergleichen soll oder nicht
Kosmetischer Natur ist.
Das wurde ja letztendlich geklärt.


gruss

[himitsu]

Ja, in PHP und Co. ist das ein Sonderfall, da dort "alles" als Boolean ausgewertet werden kann, also auch 0 und 1 oder -1 (die Integer).
Genauso, wie man das auch in Delphi machen kann, z.B. mit einen Variant.

Aber etwas umgestellt, kann man das

PHP-Quellcode:

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

auch als

PHP-Quellcode:

if (is_bool(x) and x) { ... }

darstellen und schon wird haben wir das =True auch weg, aber dort bevorzuge ich auch das Kürzere. :angle:

Ich weiß auch garnicht, ob der "Boolean" in PHP überhaupt mehr als 2 Zusände haben kann, also wie dort die Zuweisungen/Auswertungen genau arbeiten.
Wenn PHP das abfängt, dann ist ein

Delphi-Quellcode:

= True

auch nicht schlimm, wobei, wie du schon sagtest, dort

Delphi-Quellcode:

x===True

dem

Delphi-Quellcode:

x=True

im Delphi fast gleichzusetzen ist.
[edit] ich meinte natürlich

Delphi-Quellcode:

== True

... ja, ein

Delphi-Quellcode:

=

kann echt böse enden. :lol:


Ich glaub ich geh bald schlafen.

[Popov]

Zitat:

Zitat von Caps (Beitrag 1295439)

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

Um es auf den Punkt zu bringen: False ist 0. Das ist meiner Kenntnis nach das Einzige auf was man sich verlassen kann. Alles andere ist True.

Das heißt: ein Byte bietet 256 Möglichkeiten. False ist 0, die restlichen 255 Möglichkeiten sind True.

Gegen False zu prüfen sollte nie falsch sein, aber man kann mit True 254 mal daneben liegen.

[Caps]

Ich glaube in PHP sind es reservierte Wörter, aber das glaube ich nur, weil sie blau werden, wenn ich sie eintippe :lol:

Fragt sich natürlich trotzdem, wie die interne Repräsentation aussieht...

[Caps]

Zitat:

Zitat von Popov (Beitrag 1295444)

[...]
Das heißt: ein Byte bietet 256 Möglichkeiten. False ist 0, die restlichen 255 Möglichkeiten sind True.

Gegen False zu prüfen sollte nie falsch sein, aber man kann mit True 254 mal daneben liegen.

Das spricht dafür, dass nicht das Byte sondern das Bit die kleinste addressierbare Einheit sein sollte!

:drunken::drunken::drunken:
Schluss, ich muss ins Bett.

[BadenPower]

Zitat:

Zitat von himitsu (Beitrag 1295443)

Genauso wie man das auch in Delphi machen kann, z.B. mit einen Variant.

Siehe Post #12.

Wobei man dort schön sieht, dass man dann expliziet auf

Delphi-Quellcode:

if (var = true) then

prüfen muss, wenn man tatsächlich TRUE benötigt und nicht nur "ergibt Wahr".

Zitat:

Zitat von Popov (Beitrag 1295444)

Um es auf den Punkt zu bringen: False ist 0.

Wenn man sich es richtig angewöhnt, dann gibt es keine Diskussionen.

False ist nicht 0 sondern

Code:

Ord(False) = 0

[himitsu]

Zitat:

Zitat von BadenPower (Beitrag 1295447)

Wobei man dort schön sieht, dass man dann expliziet auf

Delphi-Quellcode:

if (var = true) then

prüfen muss, wenn man tatsächlich TRUE benötigt und nicht nur "ergibt Wahr".

Ja und nein ... siehe mein PHP-Beispiel

PHP-Quellcode:

if (is_bool(x) and x) { ... }

, also

Delphi-Quellcode:

VarIsBool(x) and X

.
Aber dort gibt es einen Sonderfall, denn Variant speichert den "Boolean" als WordBool (2 Byte), beim Auslesen als Boolean (1 Byte), nimmt Delphi eine Typkonvertierung vor und gibt entweder True (1), False(0) oder eine Exception (nicht konvertiervar) raus,
denn einfach nur abschneiten (billig casten) kann falsch sein, da $0100 Wahr ist, aber $00 somit ein Problem wäre.

[Popov]

Zitat:

Zitat von BadenPower (Beitrag 1295447)

False ist nicht 0 sondern

Code:

Ord(False) = 0

Der Wert von False ist 0. Es ist egal ob Ord('A') 65 ergibt, das Byte von A hat den Wert 65.

Delphi-Quellcode:

Byte(False)

[BadenPower]

Zitat:

Zitat von Popov (Beitrag 1295450)

Zitat:

Zitat von BadenPower (Beitrag 1295447)

False ist nicht 0 sondern

Code:

Ord(False) = 0

Der Wert von False ist 0. Es ist egal ob Ord('A') 65 ergibt, das Byte von A hat den Wert 65.

Delphi-Quellcode:

Byte(False)

Merkst Du was?
Du hast mich doch gerade bestätigt.

Der 'Ordinalwert von False ist 0' und nicht 'False ist 0'.
Denn "A" ist ja auch nicht 65, aber der Ordinalwert.

[Dejan Vu]

Ich habe keine Ahnung davon, sondern probiere aus:

Code:

A:=0. b := Bool(A) := FALSE. b1=true? FALSE b1=false? TRUE
A:=1.  b := Bool(A) := TRUE. b1=true? TRUE b1=false? FALSE
A:=2.  b := Bool(A) := TRUE. b1=true? FALSE b1=false? FALSE
A:=3.  b := Bool(A) := TRUE. b1=true? FALSE b1=false? FALSE
A:=FF. b := Bool(A) := TRUE. b1=true? FALSE b1=false? FALSE

Also... ähm. Bool(0) = false, alles andere ist true.... Aber dann... gilt manchmal eben auch: true <> true. Boolean(2) ist z.B. so ein Fall, aber eben auch Boolean(255).

Weswegen es -alter Hut- wirklich bescheuertnicht zu empfehlen ist, eine bool'schen Wert auf =TRUE abzufragen. Denn, wie auch schon 1024x erwähnt, gibt es durchaus Routinen (API), die eben nicht nur 0 und 1 liefern, sondern z.B. -1 (also FF). Und daher sollte man eben nur 'If Resultat then' schreiben, denn das klappt auch bei Bool(255).

Ein Variant ist übrigens kein bool'scher Wert und wenn ich einen Variant auf einen Bool'schen Wert abfragen will, dann konvertiere ich vorher sicher, denn ansonsten knallt mir der Vergleich irgendwann um die Ohren (wenn der Variant z.B. ein Array beinhaltet). Und wenn ich schon sicher konvertiere, kann ich mir die Abfrage auf '=True' auch sparen.

[Medium]

Es ist unter C auch nicht ganz unüblich, den Erfolg einer Instanzerstellung so zu prüfen:

Code:

MyClass mc = NULL;
mc = New(MyClass);
if !(mc) 
  MessageBox("Mööp!");
else
  DoSomethingWithMC(mc);

Dabei wird genutzt, dass NULL in C == 0 ist, was wiederum == false ist. Und da C nicht typsicher ist, geht diese Abomination. Wie aber true genau definiert ist, hängt überall von der konkreten Implementierung ab. Die einzige in allen Sprachen konstante Weisheit ist: false = 0
True kann alles andere was nicht 0 ist sein wenn man jetzt mal die beinhaltende Variable binär betrachtet und als Zahl interpretiert. Ob 1, -1 oder !0 (das binäre Ergebnis hängt vom hinter dem Bool stehenden Typen ab, also wie lang er ist, ob er mit Vorzeichen definiert ist oder nicht usw.) - das sind die üblichen Vertreter. Aber prinzipiell sind alle Binärwerte verschieden von 0 als true möglich. Egal ob Ord(irgendwas) nun irgendwasanderes ist oder nicht.

Wenn man für alle Fälle und immer sicher sein will, prüft man stets nur auf false, und schreibt alles was im true-Fall passieren soll in den else-Zweig. Dann wäre man immer auf der super-sonder-sicheren Seite. Ein einfaches Weglassen von =true oder =false hat bei mir bisher aber auch in Fällen der Zusammenarbeit mit C und APIs immer zum richtigen Ergebnis geführt. Entweder Glück, oder Delphi tut da relativ sinnvolle Dinge im Hintergrund. Oder ich habe bisher keine allzu bösartigen DLLs in der Hand gehabt.

[jaenicke]

Von allem Technischen mal abgesehen, das ja schon zur Genüge erörtert wurde... niemand würde sagen:
Wenn "das Wetter ist schön" wahr ist, werde ich Fußball spielen gehen.

Die meisten würden wohl eher sagen:
Wenn das Wetter schön ist, werde ich Fußball spielen gehen.

Warum sollte man beim Programmieren auf die Idee kommen das anders zu machen?

[Popov]

Jajn. In Delphi ist es so üblich. Ich weiß nicht ob es auch schon typisch Pascal war. Aber es war nicht typisch Visual Basic. So wurde ich in eine Firma gebeten meine Codes in Delphi so zu schreiben, dass auch VB-Kollegen es verstehen würden. Und mit

Delphi-Quellcode:

IF DasWetterSchoen THEN

konnten sie nichts anfangen. Das war für sie unlogisch und einig glaubten, das ich den Code bewußt unleserlich schreibe. Einige dachten, dass ich scherze. Ich sollte letztendlich den Code dann so schreiben:

Delphi-Quellcode:

IF DasWetterSchoen = TRUE THEN

, denn dass haben alle verstanden.

[BUG]

Ich kenne keine moderne Programmiersprache wo es üblich wäre, Vergleiche mit booleschen Werten zu machen. Vielleicht waren die VB-Leute in dem Schuppen einfach nur verschroben.
Edit/nevermind: Ich hab gefunden, das solche Vergleiche sogar mit in der MS-VB-Doku zu finden sind :lol:

Knobelaufgabe: Welchen Typ hat !!((!!a)-1) in C++, wenn a ein Integer ist. Wie kann man das kürzer/klarer schreiben?

[himitsu]

Zitat:

Beachten Sie, dass die Zuweisungsanweisung newCustomer = True wie der Ausdruck im vorherigen Beispiel aussieht. Sie führt jedoch eine andere Funktion aus und wird auf eine andere Art verwendet. ...

Code:

If newCustomer = True Then
   newCustomer = False
End If

Darum haben in Delphi/Pascal die Zuweisungen und Vergleiche unterschiedliche Operatoren, damit man das nicht verwechseln kann und nicht das Selbe raus kommt, so wie in PHP. :stupid:

PHP-Quellcode:

If (newCustomer = True) {
    newCustomer = False
}

Was macht denn !!?

[Dejan Vu]

Zitat:

Zitat von BUG (Beitrag 1295895)

Ich kenne keine moderne Programmiersprache wo es üblich wäre, Vergleiche mit booleschen Werten zu machen.

In C# gibt es eine ziemlich große Fraktion, die meint, das

Delphi-Quellcode:

if (!Foo)

schlecht lesbar wäre, das das '!' leicht verschluckt wiürde. Sie bevorzugen

Delphi-Quellcode:

if (Foo == false)

. Und weil es immer 'Puristen' gibt, die B sagen, wenn jemand A ruft, schreiben die dann

Delphi-Quellcode:

if (Foo == true)

Zitat:

Zitat von Medium (Beitrag 1295891)

...Die einzige in allen Sprachen konstante Weisheit ist: false = 0...
Wenn man für alle Fälle und immer sicher sein will, prüft man stets nur auf false...Ein einfaches Weglassen von =true oder =false hat bei mir bisher aber auch in Fällen der Zusammenarbeit mit C und APIs immer zum richtigen Ergebnis geführt. Entweder Glück, oder Delphi tut da relativ sinnvolle Dinge im Hintergrund. Oder ich habe bisher keine allzu bösartigen DLLs in der Hand gehabt.

Du bestätigst also eigentlich durch deine eigenen Erfahrungen die Aussagen der meisten hier.

Delphi tut hier gar nichts, außer eben, nur 0 als 'FALSE' zu behandeln. Wie pervers ein Vergleich auf 'True' oder 'False' mit anderen Werten als 0/1 ist (z.B. obskure Rückgabewerte einer DLL-Funktion) zeigt meine Aufstellung. Die besagt ja genau das, was du durch Erfahrung herausbekommen hast: Nie auf =true, =false prüfen.

[samso]

Wenn der Programmierer den Code

Delphi-Quellcode:

if Irgendwas=True then..

irgendwie logisch findet, dann kann er doch an der Stelle nicht aufhören, sondern muss eigentlich weiter machen, also:

Delphi-Quellcode:

if ((Irgendwas = True) = True) = True........ then..

?

[Neutral General]

Badenpower:

Zu dem Thema true <> 1:

Code:

asm
  xor eax, eax
  mov al, true
  nop
end;

Ob der Compiler B := 1 statt B := true zulässt oder nicht ändert nichts daran dass true = 1 ist! (B: Boolean)
true = Ord(true) = 1

[BadenPower]

Zitat:

Zitat von Medium (Beitrag 1295891)

Die einzige in allen Sprachen konstante Weisheit ist: false = 0

Ich bleibe bei meiner Meinung, dass dies sprachlich nicht richtig ist.

Wenn "false = 0" stimmen würde, dann wäre dies möglich:

Delphi-Quellcode:

 if (false = 0) then
  begin
   ShowMessage('False ist 0');
  end;

Und ich glaube an die Macht des Debuggers, der mir bestätigt, das "False" eben nicht 0 ist.


Und schauen wir doch einfach einmal was Delphi persönlich sagt:

Code:

False = False

siehe Bild im Anhang.