Delphi 6 -> Delphi 10.2

[MichaelT]

Nein. Ein Nuller genügt beim AND. Nur T AND T is T. Ist bei OR nicht anders.

[MichaelT]

Irrtum (meinerseits).

Zitat:

Zitat von mkinzler (Beitrag 1398220)

Ist einstellbar

http://docwiki.embarcadero.com/RADSt...iler-Direktive)

[FaTaLGuiLLoTiNe]

:?

Bei der verkürzten Auswertung bricht der Programmfluss ab, sobald klar ist, dass der gesamte boolsche Ausdruck wahr ist.

Bei deinem Beispiel ist doch der erste Operand des or-Vergleichs False und er kann die Auswertung nicht abbrechen, weil er auf jeden Fall noch den zweiten Operand auswerten muss um zu sehen ob dieser den Gesamtausdruck wahr macht...
wenn der erste Vergleich stattdessen True ergeben würde, dann würde der zweite Vergleich nicht mehr durchgeführt werden.

[MichaelT]

Hast du recht. Delphi bricht tatsächlich ab. Ich bin davon ausgegangen, dass das Pragma funktioniert. Da ließ ich mich verwirren. Sorry.

Zitat:

Zitat von FaTaLGuiLLoTiNe (Beitrag 1398225)

:?

Bei der verkürzten Auswertung bricht der Programmfluss ab, sobald klar ist, dass der gesamte boolsche Ausdruck wahr ist.

Bei deinem Beispiel ist doch der erste Operand des or-Vergleichs False und er kann die Auswertung nicht abbrechen, weil er auf jeden Fall noch den zweiten Operand auswerten muss um zu sehen ob dieser den Gesamtausdruck wahr macht...
wenn der erste Vergleich stattdessen True ergeben würde, dann würde der zweite Vergleich nicht mehr durchgeführt werden.

[MichaelT]

Ich hatte keinen Clean gemacht. Deswegen war ich auch überrascht.

Wenn der besagte Fehler auftritt, dann müsste man mal in die Projektoptionen schauen. Und hernach Clean und Build, zumindest zur Vorsicht.

Ändert aber nix dran dass der Code ein wenig seltsam ist.

Zitat:

Zitat von FaTaLGuiLLoTiNe (Beitrag 1398225)

:?

Bei der verkürzten Auswertung bricht der Programmfluss ab, sobald klar ist, dass der gesamte boolsche Ausdruck wahr ist.

Bei deinem Beispiel ist doch der erste Operand des or-Vergleichs False und er kann die Auswertung nicht abbrechen, weil er auf jeden Fall noch den zweiten Operand auswerten muss um zu sehen ob dieser den Gesamtausdruck wahr macht...
wenn der erste Vergleich stattdessen True ergeben würde, dann würde der zweite Vergleich nicht mehr durchgeführt werden.

[himitsu]

Zitat:

Zitat von Temi00 (Beitrag 1398221)

ist zwar off topic aber IMHO muss man beim AND immer beide Ausdrücke auswerten beim OR kann auch wegoptimiert werden. Unwahrscheinlich dass das bei Pascal anders war. Just my 2 cents ;)

Nein.

Mit der standardmäßigen kurzen Auswertung:
Bei OR wird der zweite nur ausgewertet, wenn der erste FALSE ist
Bei AND wird der zweite nur ausgewertet, wenn der erste TURE ist

Ansonsten steht das Ergebnis ja schon fest und Delphi spart sich die weitere Auswertung.
false AND irgendwas = false
true OR irgendwas = true

Darum kann man in Delphi standardmäßig auch sowas machen

Delphi-Quellcode:

if Assigned(irgendwas) and irgendwas.wasanderes then

Bei anderen Sprachen, die immer voll auswerten, oder wo die Auswertereihenfolge sich ändern kann, da geht das nicht.
z.B. in einigen DBMS (SQL), wo immer vollständig ausgewertet wird und wo der Queryplaner nach Gutdünken die Auswertung umdrehen kann.

[DeddyH]

Im zitierten Text stand doch nichts anderes.

[MichaelT]

Der Fehler sofern dieser dort auftritt kommt aber genau von der Abwesenheit der Kurzschlussauswertung. Wenn der Autor sonst nichts angegriffen hat.

Das war ein Reply auf meinen Irrtum, obwohl dieser auch nur teilweise zuschlug.

Ich hatte mich nur kurzfristig davon ablenken lassen, dass das Pragma nicht mehr funktioniert sondern die Einstellung auf das Projekt bezogen ist. Ich habe zwar dann geschnallt, dass die Pragmas offensichtlich überlesen werden, vermute ich zumindest, aber nicht regelmäßig einen Clean vor dem Build nach dem Umschalten der Projekt Settings.

Der Grund wäre der naheliegende. Stellt sich die Frage warum? Im Projekt global aufgedreht, da Projekt konvertiert - wäre möglich kann ich aber nicht testen.

Wenn dem nicht so wäre beleibt die Frage ob das Pragma {B+] doch irgendwie zieht wenn es im Quellcode steht. Wenn ja, dann muss jedes Element initialisiert gewesen sein. Sonst kann der Code nicht zu dem vermuteten Fehler passen.

Davon mal abgesehen

Delphi-Quellcode:

if (Current <> nil) and (Current.Character = Value) then ...

War einfacher zu lesen. Result ist zu Beginn schon nil.


Bei einem neuen Projekt funktionierts es. Also bleibt nicht viel.

erweiterte Variante (abenteuerlich): Complete Boolean avail gelte hieße, dass immer ein initialisiertes Objekt vor gefunden wurde und die Value. Wäre das der Fall gewesen, dann müsste sich am Aufbau des Baums etwas geändert haben, resp. an der Quelle aus der dieser Baum wird erzeugt.

zum Code: Es genügte vollkommen in einer Schleife zu prüfen ob das Objekt initialisiert ist und drinnen einfach die Value abzufragen. Es wird allein beim ersten Auffinden einer Value die Schleife verlassen. Sauberer wäre eine Variable canContinue und wenn man den nächsten Nachfolger liest diese zu setzen in Abhängigkeit ob die Value gefunden wurde.

Zitat:

Zitat von himitsu (Beitrag 1398241)

Zitat:

Zitat von Temi00 (Beitrag 1398221)

ist zwar off topic aber IMHO muss man beim AND immer beide Ausdrücke auswerten beim OR kann auch wegoptimiert werden. Unwahrscheinlich dass das bei Pascal anders war. Just my 2 cents ;)

Nein.

Mit der standardmäßigen kurzen Auswertung:
Bei OR wird der zweite nur ausgewertet, wenn der erste FALSE ist
Bei AND wird der zweite nur ausgewertet, wenn der erste TURE ist

Ansonsten steht das Ergebnis ja schon fest und Delphi spart sich die weitere Auswertung.
false AND irgendwas = false
true OR irgendwas = true

Darum kann man in Delphi standardmäßig auch sowas machen

Delphi-Quellcode:

if Assigned(irgendwas) and irgendwas.wasanderes then

Bei anderen Sprachen, die immer voll auswerten, oder wo die Auswertereihenfolge sich ändern kann, da geht das nicht.
z.B. in einigen DBMS (SQL), wo immer vollständig ausgewertet wird und wo der Queryplaner nach Gutdünken die Auswertung umdrehen kann.

[Temi00]

Zitat:

Zitat von MichaelT (Beitrag 1398251)

Der Fehler sofern dieser dort auftritt kommt aber genau von der Abwesenheit der Kurzschlussauswertung. Wenn der Autor sonst nichts angegriffen hat.

Ich hab jetzt in den Projekt Optionen einen Schalter gefunden "Complete Boolean Evaluation" Der war auf True. Komisch da im Internet steht default False;

Habe nun auf False gesetzt. make clean. Und nochmal mit debugger gestartet. Wieder die selbe Stelle. Das verstehe ich nun überhaupt nicht. Current ist ja nun defintiv nil und dann sollte der zweite Ausdruck ja nicht mehr geprüft werden.

habe dann kurz voher

{B-} eingefügt jetzt ist der Fehler an anderer Stelle
{B-} wieder entfernt Fehler bleibt an dieser anderen Stelle ???
Da ich ja den Source geändert habe dürfte ein make clean ja nicht nötig sein. Trotzdem clean aber der Fehler bleibt da (an dieser zweiten Stelle) Ich glaub ich schmeiss die Flinte ins Korn. Der externe soll nochmal ran. Ich brauch erst ein Kurs (Für Pascal und IDE)

Danke erst mal

[MichaelT]

Ich würde mal im Projekt die Einstellung auf False lassen. Die hast du vermutlich umgestellt.

Interessant bei mir reagiert der Compiler auf das Pragma nicht, auf die Project Settings schon. Ich bin unter Delphi 10.2 (pur).

Wir müssen die richtige Stelle finden an der dieser Fehler passiert. Also können wir nichts ausschließen. Schön wäre es gewesen.

Aus der Ferne kann ich nichts sagen und ich bin vermutlich ganz weit weg.

Frage: Wie weit weg von dieser Codestelle ist woanders?

Wenn dann müssten wir mit {B-} und {B+} den Bereich einschränken.

Aber zuvor gibt es noch die Einstellungen am Package selbst und nicht nur im Projekt. Aber plag ich nicht.

Zitat:

Zitat von Temi00 (Beitrag 1398301)

Zitat:

Zitat von MichaelT (Beitrag 1398251)

Der Fehler sofern dieser dort auftritt kommt aber genau von der Abwesenheit der Kurzschlussauswertung. Wenn der Autor sonst nichts angegriffen hat.

Ich hab jetzt in den Projekt Optionen einen Schalter gefunden "Complete Boolean Evaluation" Der war auf True. Komisch da im Internet steht default False;

Habe nun auf False gesetzt. make clean. Und nochmal mit debugger gestartet. Wieder die selbe Stelle. Das verstehe ich nun überhaupt nicht. Current ist ja nun defintiv nil und dann sollte der zweite Ausdruck ja nicht mehr geprüft werden.

habe dann kurz voher

{B-} eingefügt jetzt ist der Fehler an anderer Stelle
{B-} wieder entfernt Fehler bleibt an dieser anderen Stelle ???
Da ich ja den Source geändert habe dürfte ein make clean ja nicht nötig sein. Trotzdem clean aber der Fehler bleibt da (an dieser zweiten Stelle) Ich glaub ich schmeiss die Flinte ins Korn. Der externe soll nochmal ran. Ich brauch erst ein Kurs (Für Pascal und IDE)

Danke erst mal