Bitweises AND

[Benmik]

In einer Unit findet sich folgender Code:
lBaseRecord := (PInt64(@fr[$20])^) and $0000FFFFFFFFFFFF; .
Ich weiß, was auf Bitebene passiert und ich weiß auch, dass man mit einem bitweisen AND prüfen kann, ob ein bestimmtes Bit gesetzt ist.
Aber kann jemand mir mal erklären, wozu das eigentlich gut ist? Was macht diese Codezeile mit BaseRecord (einem Int64)? Was erreicht man damit, wann setzt man sowas ein?

[Uwe Raabe]

Es setzt die oberen 16 Bit des 64-Bit Werts auf 0. Warum das da gemacht wird kann ich dir ohne Kontext auch nicht sagen.

[Benmik]

Ah, das bringt schon etwas Licht. (Das konkrete Beispiel ist mir nicht wichtig). Aber was passiert mit den unteren 48 Bit? 00 ist 0, das verstehe ich. Aber ist FF dann 1, oder jedenfalls nicht 0? Müsste das die Bits von lBaseRecord beim Vergleich mit FF nicht auch ändern, je nachdem, ob dort 00 oder nicht 00 steht?

[DeddyH]

https://www.delphipraxis.net/95180-e...bitmasken.html
Hilft das weiter?

[Benmik]

Das ist eine sehr schöne Anleitung! Dauert vermutlich etwas, bis das in die tieferen Synapsenschichten sinkt.
Also ist es so: Die oberen 16 Bit werden alle auf 0 gesetzt, weil der Vergleich mit 0 immer 0 ergibt. Die unteren werden auf 1 gesetzt, wenn sie 1 sind und auf 0, wenn sie 0 sind. Das könnte eventuell dazu führen, dass sie schlicht gleich bleiben, was so ziemlich das ist, was Uwe geschrieben hat. Cool.
Benutzt man bitweises AND eigentlich in der Regel, um Flags auszulesen, oder gibt es (mal abgesehen vom vorliegenden Beispiel) noch eine häufiger gebrauchte Verwendung?

[DeddyH]

Einerseits wird das gern bei Flags genutzt, andererseits auch in der Netzwerktechnik, z.B. um zu ermitteln, ob sich 2 Rechner im selben Netzwerksegment befinden, zumindest bei IPv4.

[Benmik]

Interessant. Danke.

[Alallart]

Man möge mich verbessern wenn ich deine Frage falsch verstanden habe...

Nehmen wir an wir haben den Wert 1.000.000.000 und AND'en ihn mit einer anderen Zahl

1.000.000.000	0011 1011 1001 1010 1100 1010 0000 0000	AND
4.294.967.295	1111 1111 1111 1111 1111 1111 1111 1111
1.000.000.000	0011 1011 1001 1010 1100 1010 0000 0000	Ergebnis

Ergebnis ist, dass nur da wo die Bits 1 und 1 sind, Ergebnis 1 ist. Wo 1 und 0 sind, ist das Ergebnis 0.

Vielleicht ist das Beispiel oben zu langweilig:

x	0011 1011 1001 1010 1100 1010 0000 0000	AND
x	0000 0000 0000 0000 1111 1111 1111 1111
x	0000 0000 0000 0000 1100 1010 0000 0000	Ergebnis

Oder anders

x	0011 1011 1001 1010 1100 1010 0000 0000	AND
x	1111 1111 1111 1111 0000 0000 0000 0000
x	0011 1011 1001 1010 0000 0000 0000 0000	Ergebnis

Oder anders

x	0011 1011 1001 1010 1100 1010 0000 0000	AND
x	0000 0000 0000 0000 0000 0000 0000 0000
x	0000 0000 0000 0000 0000 0000 0000 0000	Ergebnis

[Redeemer]

Bitoperatoren mit vorzeichenbehafteten Zahlen (wie Int64 im OP) zu verwenden ist etwas befremdlich da manchmal unintuitiv.

[Rollo62]

Zitat von Redeemer:

Bitoperatoren mit vorzeichenbehafteten Zahlen (wie Int64 im OP) zu verwenden ist etwas befremdlich da manchmal unintuitiv.

Das stimmt,
aber die Bits sind ja erstmal gleich für Int64 und UInt64.
Der Bit-Operation sollte das erstmal egal sein.
Erst nach der Bit-Operation wird die Bewertung (Signed/Unsigned) gemacht,
und da könnte man schonmal logisch leicht daneben liegen.