TRUE/FALSE Part

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