Das deutsche QBasic- und FreeBASIC-Forum

[OneCypher]

Einfach mal ausprobieren:

Funktioniert, wie es soll:

[croco97]

Nein, kein Bug. Mit FB kann man halt auch Unsinn machen und das hier ist doch eher Unsinn. In FB gilt: TRUE=-1 und FALSE=0. Falls ein Wert ausserhalb {0,-1} liegt, dann gilt im Zweifelsfall TRUE.

Du siehst: Mit unsigned Werten Booleans zu betreiben ist das Gleiche wie mit Kühen nach Korallen zu tauchen: Kühe sind nun mal nicht unterwassertauglich.

Dein letzter Code funktioniert nur vermeintlich: 1<>0 ist TRUE, wird im UBYTE damit aber als 255 gespeichert und ergibt nur über den "Notausgang" zufällig wieder TRUE. Setze an die Stelle mal (1<>0)-5 ein und du bekommst auch TRUE. (1<>0)-255 ist übrigens FALSE.

VG!

Croco

[MisterD]

die Erklärung ist wie immer in dem fall nicht ganz richtig ;D

0 entspricht false
alles andere entspricht true. das "standard"-true ist halt definiert als "NOT 0", und weil NOT bitweise arbeitet kommt bei "NOT &b00000000000000000000000000000000;" eben dann &b11111111111111111111111111111111; raus als ergebnis. Und das als Zweierkomplement Integer gelesen ist eben -1.

meine Vermutung bezüglich dem UByte-Problem:

im Integer-Fall passiert folgendes:
a = 1 <> 0 produziert das standard-true, also a=&b11111111111111111111111111111111;
(NOT a) dreht dann alle einsen und nullen um, ergibt also &b00000000000000000000000000000000;
und das ist eben tatsächlich false.

im UByte-Fall dagegen passiert folgendes:
a = 1<>0 produziert erneut das standard-true, allerdings wird der wert abgeschnitten weil ubyte nur 8 bit groß ist, also a=&b11111111;
(NOT a) wandelt dann zunächst a in Integer um weil NOT eben nur Integers als parameter nimmt oder so, zumindest keine UBytes. ausgerechnet wird also (NOT &b00000000000000000000000011111111;)
das ergebnis hiervon ergibt natürlich dann nach dem tauschen aller einsen und nullen &b11111111111111111111111100000000; - das ist offensichtlich nicht 0, also wird es als true gewertet.
folglich sind beide if's dann true, deswegen verhält sich das programm so komisch.


So ist das eben, wenn man mit einer Programmiersprache arbeitet, die auf Uralt-Basic aufbaut und daher weder einen bool-datentyp noch boolsche rechenoperatoren (was einem in dem fall eben das genick bricht, den datentyp könnte man ja noch ignorieren aber das halt nicht) - sondern eben nur bitweise operatoren die eben nicht dasselbe tun.


Workaround ist in dem Fall ganz einfach: Benutz kein UByte. Speicher sparen wollen ist zwar ne nette sache, aber ich würde fast wetten, dein Programm ist mit UByte sogar langsamer als mit Integer weil die CPU sowieso alles als 32bit-Werte verarbeitet - auch UBytes. und wenn du viele boolean-werte speichern willst und deshalb ubyte benutzt damit das array nicht zu groß wird - auch blödsinn, da hast du immernoch 7 bit verschwendung pro bit was zählt, dann arbeite lieber mit nem Integer-Array und schreib dir vernünftige zugriffsmethoden mit BIT() - siehe referenz
_________________
"It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."
Edsger W. Dijkstra

[OneCypher]

@MisterD: Das nenn ich mal eine akurate antwort .. vielen dank! .. werd auf jeden fall nun nur noch integer einsetzen um 2 Zustände zu speichern..
@croco97: Auch vielen Dank für deine Antwort!

Aber eigentlich hätten die Herrn FB-Programmierer diese Funktion auch für Ubyte-Parameter überladen können....

[MisterD]

Was du versuchen kannst ist, byte zu verwenden ohne U.

Dadurch dass Ubyte &b11111111; = +255 ist wird daraus natürlich Integer +255. Wenn du aber Byte &b11111111; = -1 hast sollte daraus auch wieder Integer -1 werden und das ganze würde wieder funktionieren.

Aber wie gesagt, byte-Variablen sollte man da benutzen wo man sie wirklich braucht, ansonsten machen sie nur potentiell stress mit dem Alignment im speicher und erzeugt eher einen negativen effekt, zumindest solang man sie einzeln verwendet. Wie gut aber dass man da als Programmierer nichts von sieht, nicht? ;D
_________________
"It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."
Edsger W. Dijkstra

[nemored]

Oder du verwendest statt IF a und IF (NOT a) den Vergleich IF a<>0 und IF a = 0. Ist nur ein wenig mehr zu schreiben und sicherer.
_________________
Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1.

[MisterD]

dafür unverständlich lesbar also besonderes beschissen ;D
_________________
"It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."
Edsger W. Dijkstra