Zitat:
Der Cast auf Boolean soll doch ein Cast sein, der die Daten nicht verändert, sondern nur den Typ.
Das ist doch gerade der Kernpunkt des ersten Teil des Tutorials!
Würde man deine Konstruktion verwenden, bekäme man in diesem Fall keine Probleme mit einem expliziten Vergleich auf true oder false.
if Boolean = True then
sollte man NIEEEEEEE schreiben....
...dies kann richtig sein, aber muss nicht richtig sein
Ich weis nicht, dein "Tutorial" zieht meiner Meinung nach die falschen Schlußfolgerungen.
Ist zwar eine umständliche Boolsche Auswertung aber immer noch eine
korrekte und PASCAL konforme Auswertung die immer
richtig umgesetzt wird. Es ist egal ob man dabei den Typen Booelan, WordBool, Bool, ByteBool oder LongBool benutzt.
Das eingentliche Problem mit falschen Auswertung solcher Konstrukte liegt im
CAST eines beliebigen Wertes in einen Boolean Datentyp. Robert hat also oben schon absolut die saubere Lösung zur Vermeidung solcher CASTs aufgezeigt.
Denn das nun
Delphi-Quellcode:
if Boolean then
// oder
if not Boolean then
mit casted Datentypen denoch korrekt funktioniert liegt
ausschließlich nur an der Art & Weise wie der Compiler diese Abfragen in Maschinencode umsetzt. In diesem speziellen Falle erzeugt nämlich der Compiler keinen direkten Vergleich zweier Datenwerte zueinander sondern benutzt
spezielle Features der CPU die immer quasi ein
Auschlußverfahren anwenden. Auf Grund dessen ist FALSE als 0 definiert und der Compiler erzeugt einen Code der <> 0 oder == 0 testet, je nach TRUE oder FALSE Bedingung.
Das der Compiler dies so macht ist keine zwangsläufige und dokumentierte Grundlage zur Auswertung Boolscher Bedingungen. Dieses Verhalten ist undokumentiert und man kann sich darauf nicht verlassen !
Der Compiler könnte also interen selber ebenfalls einen direkten Wertvergleich durchführen, dh. also aus
Delphi-Quellcode:
if Boolean then
// macht der Compiler einen Maschinencode wie
if Boolean = Truee then
und würde dann ebenfalls auf die Schnauze fallen mit casted Boolean's.
Die eigentliche Ursache des Problems liegt also nicht in der Art & Weise der
Abfrage eines Booleans sondern in der
Erzeugung eines Booleans per TypCasts !!
Ergo: Sich hinzustellen und zu behaupten das eine PASCAL konforme Abfrage schlecht wäre und zu Fehlern führt ist die falsche Konsequenz. Dies stimmt nicht, da die Ursache einzigst im Cast eines Datentypes liegt. Man kann zwar versuchen den Schimmelbefall eines Hauses durch einen sauberen Anstrich zu verdecken, aber nur die Beseitigung des Übels schafft wirklich abhilfe. Das macht aber einen schlechteren Hausanstrich nicht verantwortlich dafür das der Schimmelbefall immer noch da ist.
Das die umständliche Abfrage eines Boolschen Datentypes per zusätzlichem Boolschen Vergleich doppelt gemoppelt ist und somit sehr un-clever ist sei unbestritten, aber nicht
falsch im Sinne der PASCAL Semantik.
Schaut mal den IT Professoren auf Bayern3 im <IT> Grundkurs zu und was die für schreckliche PASCAL Sourcen als Lehrmittel heranziehen. Da habe ich solche doppeltgemoppelten Boolschen Abfragen schon sehr oft gesehen.
Gruß Hagen
[edit]
Die Frage eines Stils des "Bullet proof" Programmieren kann man aber mit deinem Tutorial sehr wohl begründen. Es ist also sauberer Boolsche Datentypen direkt Boolsch auszuwerten und macht auf Grund der speziellen Auswertung solcher Abfragen durch den Compiler den Code sicherer. Aber er wird dadurch nicht richtiger als die un-celvere Art der Boolschen Abfragen !
[/edit]