Hallo Leute!

Angeregt durch eine andere Diskussion (www.delphi-forum.de/viewtopic.php?t=82728), habe ich mich mal damit beschäftigt, was passiert, wenn man boolsche Variablen (also tatsächlich das reine boolean, nicht ByteBool, WordBool, LongBool) per Vergleich abfragt, so z.B.


statt einfacher:



Erstaunt nahm ich zur Kenntnis, daß "if a then" sicher reagiert, dazu im Gegensatz "if a=true then" nicht, auch dann nicht, wenn a tatsächlich den Wert true besitzt.

Bis dato glaubte ich, daß dieses überflüssige Vergleichen bzw. vergleichende Prüfen nur redundant, also "unsauber" ist, aber nicht existentiell (anscheinend aber in manchen Fällen doch). Weiß jemand genaueres?

Außerdem hielte ich es für angebracht, daß der Compiler wenigstens einen Hinweis auf das Prüfen boolscher Variablen gäbe, aber das ist ein anderes Thema.

Siehe hier: www.michael-puff.de/...h_Wahrheitswerte.php

Oh jippie, Antwort kam schneller, als die Polizei erlaubt - herzlichsten Dank!!

Hi
Nun zur Verwirrung will ich mich denn auch mal äußern, da mir die Erklärung von Michael noch nicht ganz schlüssig erscheint.

True ist doch nach der Aussage Konstante -1 und False Konstante 0 also ließe es sich doch abfragen

wenn die Logik stimmt....
Vermutlich ist aber True nicht immer Konstant -1, da auch hier eben nicht nur ein Bit, sondern mindestens ein Byte benutzt wird und daher nur der Wert 0 ( alle Bitts =0) eindeutig ist, nicht aber die 255 anderen möglichen Werte. Eine schlüssige Erklärung ist dies aber auch noch nicht, warum das True nicht eindeutig definiert ist.
Gruß oldmax

Das Problem tritt doch nur bei undefinierten bool'schen Variablen oder dreckigem Typecasting auf.

Bei sauberer Programmierung sollte bzw. wird(!) eine Abfrage auf (=TRUE) immer das gleiche Ergebnis wie die direkte Auswertung des Terms liefern. Das ist auch logisch, weil dann jeder Boolean-Wert immer genau entweder 'True' oder 'False' ist.

Der Fehler ist: alle Werte <> 0 als 'True' anzunehmen. Das ist so dermaßener Quark, das man sich fragt, wer auf so einen kranke Definition gekommen ist (Borland, ich weiss). Denn das ist doch schon mathematisch Blödsinn: Der Datentyp 'bool' hat genau zwei Werte. True oder False. Wie True bzw. False intern dargestellt werden, interessiert mich nicht.

Hier ist das Typecasten der Casus Knactus: Vergleichen wir mal das Verhalten einer Enumeration mit dem Datentyp Bool:


Hier haben wir einen echten Designfehler von Delphi, denn es ist nun wirklich so, das True<>True ist, bzw. die Aussage True=True nicht stimmt bzw. ist der Wert 'True' nicht eindeutig. Und das soll ein Datentyp sein, mit dem man logisch rechnen kann?

Ich meine, das die 'Wahrheit' (True) mehrere Facetten haben kann, bzw. sich Wahrheiten ausschließen können, ist zwar philosophisch interessant, aber nicht mathematisch. Insofern hätte Borland den Datentyp 'Boolean' in 'PhilosophicBoolean' umbenennen sollen. Dann gäbe es nämlich die reine Wahrheit (True), sowie beliebig viele andere Wahrheiten (<>False)...

Nur als kleiner Hinweis:

Wie wärs mit:

Die Geschichte von "true := <> 0" kommt aus der C-Welt.

Da es dort keine boolschen Werte gibt, sondern nur Zahlen und Zeichen, wurde das halt so definiert.

Ist zum Auswerten von Zahlen auch gar nicht so blöd:



funktioniert so eben auch, wenn testFunktion einen numerischen Wert zurück liefert.

Jupp, genau und bei API-Funktionen mus True eben nicht immer unbedingt -1 sein.

Der Grund ist sonnenklar, aber Delphi/Pascal als typenstrenge Sprache bzw. der Compiler und die Delphi-Sprachdefinition hätte hier (also beim Typecasten) etwas mehr Magic einbauen müssen. Das C das locker sieht, ist eh klar. C sieht ALLES locker.

Warum? Ich finde es weder schön noch sinnvoll überhaupt mit true oder false zu vergleichen, ich habe ja schon einen boolschen Wert. Dass da jemand überhaupt auf die idee kommen könnte, darauf muss man erstmal kommen. Und durch Compiler-Magic dort herumzubasteln könnte vielleicht auch andere Probleme bringen, wenn das Verhalten erwünscht bzw. notwendig ist wegen einer API...

Grundsätzlich denke ich jedenfalls, dass das Problem eher von schlechten Anfängerseiten oder Lehrern herrührt, die so etwas überhaupt machen. Ich wäre nie auf die Idee gekommen das so zu machen, weil ich es selbst alles ausprobiert und nur mit der Delphi-Hilfe erarbeitet habe. (Ich hatte kein Internet...)

Das Problem ist, das für alle boolschen werte gelten muss : True = True.

Hier haben wir: Boolean(1) = True und Boolean (2) = True, aber Boolean(1)<>Boolean(2), ergo True<>True. Das erkläre mal einem Mathematiker.

Das ist die Grütze, bzw. der ästhetische Designfehler in Delphi. Das man nicht auf '=true' vergleichen sollte, ist imho logisch.

Das Problem: Delphi müsste dann überprüfen ob der Wert nicht dem Standardtrue entspricht und den Wert darauf setzen. Nur verbraucht das Rechenzeit.

Und bei sauberer Programmierung hatte ich noch nie ein Problem damit, auch nicht, wenn API-Funktionen nicht unbedingt das Standardtrue geliefert haben, deshalb hielte ich es für falsch zusätzlichen Code einzubauen für diese Prüfung.

Einfach immer "<> false" prüfen

baka0815 hat folgendes geschrieben:

Einfach immer "<> false" prüfen

Nein

Ein Boolean ist schon ein Boolean!

Also statt

Hi,

Ich glaube das <> false war mit einem lächelnden Auge

Als ich mich mit der absoluten Asymmetrie des Boolean-Typs beschäftigt habe, konnte ich mir das eigentlich nur so erklären: Vergleiche von Zahlen müssen ja vom Prozessor umgesetzt werden.

Nun könnten diese Vergleiche durch bitweise Verfahren(Xor für ungleich, etc.) ablaufen. In diesem Fall wäre es günstig, wenn man direkt das Ergebnis dieser Bitweisen Operation ausgeben könnte, statt es wiederum in zwei konstante Werte umzucasten.
Das sage ich jetzt als Laie, der sich nur mal Gedanken über eine potentiell doch vorhandene Logik gemacht hat.

Natürlich ist Kompatiblität bereits Grund genug: Wenn C Boolean so umsetzt, ist der Delphi-Datentyp kompatibel zu C(Was man aber imho nur z.B. beim C-Auslesen aus einer Datei, die mit einem Delphi-basierten Programm geschrieben wurde, gebrauchen kann).

mfG,

Hidden hat folgendes geschrieben:

Ich glaube das <> false war mit einem lächelnden Auge

Das habe ich gehofft und deshalb auch nicht weiter was dazu geschrieben, aber ich finds halt nicht gut, sowas zu schreiben, was ja auch andere lesen, denen nicht klar ist, dass das Blödsinn ist. Deshalb die Smileys .

Hidden hat folgendes geschrieben:

Natürlich ist Kompatiblität bereits Grund genug: Wenn C Boolean so umsetzt, ist der Delphi-Datentyp kompatibel zu C(Was man aber imho nur z.B. beim C-Auslesen aus einer Datei, die mit einem Delphi-basierten Programm geschrieben wurde, gebrauchen kann).

Nein, der Grund sind vor allem die bereits erwähnten API-Aufrufe . Denn die gehen von diesem boolschen Verhalten aus, da die Windows API (genau wie andere APIs) in C geschrieben ist.

Eigentlich wäre das doch einfach: Wir definieren: False = 0, True = 1.
Typecasting wäre 1 Pikosekunde langsamer, weil nun der Code 'Wenn <> 0 dann 1' eingefügt wird (damit das Typecasting auf Boolean wieder genau einen(!) der beiden möglichen Werte liefert).

So kenn ich das übrigens aus anderen Sprachen und Pascal-Derivaten.

Aber neeee, Delphi muss ja immer zu C(++) schielen Ach, was solls. Ich programmier einfach sauber und ordendlich, dann ist mir das doch Schnurz.

Hidden hat folgendes geschrieben:

Hi, Ich glaube das <> false war mit einem lächelnden Auge

Japp, war es. Ich dachte der Smiley dahinter würde ausreichen.

Warum genau man einen boolschen Ausdruck nochmal auf solchen prüfen sollte, ist mir jedoch auch nicht klar. Sinn macht sowas nur, wenn man einen undefinierten Zustand braucht, also "true", "false" und "undefinded" (bzw. FileNotFound falls das wer von DailyWTF kennt ).

Hey, siehste... die hatten damals schon Quantencomputer im Auge

Stimmt aber eigentlich... könnte man TriState Logik ganz einfach mit implementieren...