AND, OR, XOR

[Josef Sniatecki]

Weil sich schon viele User unsicher waren, wie die logischen Verknüpfungen
AND, OR und XOR von PureBasic verarbeitet werden, werde ich mal hier
alles in diesem Thread klar machen.

Wir nehmen mal an, dass der Ausdurck vor der Verknüpfung "L" heißt und
der nach der Verknüpfung "R".

Code: Alles auswählen

If X() and Y()

In diesem Ausdruck, wird L (also "X()") immer ausgeführt. Ist L nicht
wahr, dann wird R erst garnicht begonnen. D.h. die Funktion Y() wird nicht
aufgerufen, wenn X() "0" zurückgibt.

Code: Alles auswählen

If X() Or Y()

Wenn L wahr ist, dann wird R nicht ausgeführt.

Code: Alles auswählen

If X() XOr Y()

Bei XOR werden immer L und R ausgeführt und ausgewertet. Es wird
also nie ein Ausdruck ausgelassen.

Wenn man über das alles bescheid weiß, kann man folgedes machen:

Code: Alles auswählen

If *Pointer And *Pointer\L=10
  ...

Man ist sich bewusst, dass "*Pointer\L" zu einem Fehler führen kann,
wenn "*Pointer" auf Null zeigt. Doch wenn *Pointer gleich 0 ist, dann
wird der zweite Ausdruck ("*Pointer\L=10") nach dem AND erst garnicht
ausgeführt. Und so kommt es dann auch nicht zu einem Fehler.



Ich hoffe ich konnte euch damit helfen.
Gruß Josef

[Kaeru Gaman]

sorry, aber dein zweiter absatz ist nicht korrekt.

solche konstrukte ergeben nur sinn, wenn der vergleichs-operator
und der zuweisungs-operator verschiedene zeichen sind.

die abfrage ob *Pointer\L gleich 10 ist, ergibt nicht dann einen fehler,
wenn der pointer #Null ist, sondern dann, wenn er nicht Long strukturiert ist.

[PMV]

Die rede ist von einem Laufzeitfehler, nicht von einem Compilerfehler. Ist
*Pointer = 0 wird versucht an der Speicheradresse 0 ein Longwert aus zu
lesen.

MFG PMV

[Kaeru Gaman]

hm...
so gesehen, ok, dann versteh ich den gedanken dahinter.

gibt ja nur mindestens 2^31 andere werte als 0 die nen IMA erzeugen,
sehr sinnvolle fehlervermeidung.

[PMV]

Ich nutz das eigentlich sehr häufig ... z.b. für übergabeparameter in
Prozeduren, die aber auch nicht unbedingt nötig sind. Und wenn man das
nicht möchte, bleibt es 0. Wenn AllocateMemory() fehl schlägt, wird 0
zurück gegeben. Alle 2^31 anderen Werte sind (in der theorie) also keine
Fehler. Und es geht auch nicht darum, alle möglichen Fehler aus zu
schließen, die irgend ein Programmierer machen könnte, sondern nur die
Offensichtlichen oder solche, die als Alternative funktionieren sollen

Wie war das noch mal, als Dieter Nur von "Unerwarteten Fehlern"
gesprochen hat? ... Super! Die anderen waren also alle erwartet


MFG PMV