Hallo,

was mich aber ein wenig stutzig macht, ist die -1. Warum denn ein negativer Wert? Das heißt doch, dass da ein ganzer Integer reserviert wurde. Aber eigentlich würde doch ein einzelnes Byte reichen!? Und ich glaube zu wissen, dass beim Speichern eines Booleans in Streams nur ein Byte geschrieben wird. Ich kann mich aber auch irren.

Grüße,
Yogu

Yogu hat folgendes geschrieben:

Was mich aber ein wenig stutzig macht, ist die -1. Warum denn ein negativer Wert?

Wenn du -1 ins Dualsystem umrechnest, erscheint das logisch: -1 = 0%11111111. Ob der Wert (wie hier bei einem Byte) als -1 oder als 255 interpretiert wird, hängt von der Implementierung ab.

Yogu hat folgendes geschrieben:

Das heißt doch, dass da ein ganzer Integer reserviert wurde. Aber eigentlich würde doch ein einzelnes Byte reichen!?

Theoretisch ja, aber auf einer 32-Bit-Plattform sind alle Rückgabewerte und Parameter 32 Bit groß, weswegen die Bytegröße den Aufwand nur vergrößern würde. (Außerdem wird (normalerweise) durch das Alignment eh ein QWord belegt.)

Hallo,

Silas hat folgendes geschrieben:

Wenn du -1 ins Dualsystem umrechnest, erscheint das logisch: -1 = 0%11111111. Ob der Wert (wie hier bei einem Byte) als -1 oder als 255 interpretiert wird, hängt von der Implementierung ab.

Ah, das klingt logisch.

Silas hat folgendes geschrieben:

Auf einer 32-Bit-Plattform sind alle Rückgabewerte und Parameter 32 Bit groß, weswegen die Bytegröße den Aufwand nur vergrößern würde.

Stimmt, davon hab ich auch schonmal gehört / gelesen. Wahrscheinlich werden die überflüssigen drei Byte beim Speichern dann wieder entfernt.

Silas hat folgendes geschrieben:

Außerdem wird (normalerweise) durch das Alignment eh ein QWord belegt.

Äh, bist du dir da sicher? 64 Bit? War das ein Schreibfehler, oder meinst du wirklich, dass da immer genau doppelt so viel wie nötig reserviert wird?

Grüße,
Yogu

Yogu hat folgendes geschrieben:

Silas hat folgendes geschrieben: Auf einer 32-Bit-Plattform sind alle Rückgabewerte und Parameter 32 Bit groß, weswegen die Bytegröße den Aufwand nur vergrößern würde. Stimmt, davon hab ich auch schonmal gehört / gelesen. Wahrscheinlich werden die überflüssigen drei Byte beim Speichern dann wieder entfernt.

Nein, ein Boolean ist genauso 32 Bit groß wie ein Integer, weil auf nem 32-Bit-System 32 Bit am einfachsten zu handlen ist.

Yogu hat folgendes geschrieben:

Silas hat folgendes geschrieben: Außerdem wird (normalerweise) durch das Alignment eh ein QWord belegt. Äh, bist du dir da sicher? 64 Bit? War das ein Schreibfehler, oder meinst du wirklich, dass da immer genau doppelt so viel wie nötig reserviert wird?

Nein, AFAIK werden Variablen immer am Alignment ausgerichtet, und das ist bei Delphi IIRC immer ein QWord, also 64 Bit.

Bitte nicht haun, wenn da was nicht stimmt

Zwei Dinge:

1. True ist in Delphi als 1 definiert (Siehe System.pas, wer's nicht glaubt).

2. Booleans sind 8 Bit (1 Byte) groß, werden aber aus Performance-Gründen oftmals in einem 32-Bit-Register übergeben un verarbeitet.

@Tri-State-Logik: Warum nicht: if Byte(a) > Byte(True) Then //Tristate
Somit hätten wir auch die Programmierer abgedeckt, die an eine Größere Wahrheit(TM) beim Arbyten denken

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Dann könnte man auch endlich Boolean auf die Antwort prüfen und die Berechnung da gleich abbrechen.. praktisch

BenBE hat folgendes geschrieben:

True ist in Delphi als 1 definiert (Siehe System.pas, wer's nicht glaubt).

Oh, dann war das QBasic...

Für 'nen richten Boolean würde eigentlich 1 Bit reichen, gibt ja nur zwei Werte. Aber das wird vermutlich zu schwierig das Bit aus dem Byte raus zu holen...

Hallo,

ein einzelnes Bit kann (zumindest Windows) nicht verwalten, Es muss immer mindestens ein Byte reserviert werden. Das ist auch gut so, denn sonst wären die Speicheradressen ja acht mal so groß

Un das "rausfiltern" eines Bits dauert länger als ein direkter Vergleich. Da müsste nämlich der Wert erst mit $00000001 UND-verbunden werden, bevor auf =$00000001 geprüft werden kann. Andernfalls reicht ein einzelner Assembler-Befehl, um auf Nicht-Null zu prüfen.

Grüße,
Yogu

Hi,

Also prinzipiell sehe ich das Problem nicht, die bisherigen Einsprungpunkte(alle 8 bits) beizubehalten und trotzdem über einen Index auf die einzelnen Bits eines Bytes zuzugreifen(MyByte[6]).

Dann müsste aber das komplette Byte mit 8 Booleans gefüllt sein. Bei größeren Boolischen Arrays könnte das aber doch nützlich sein.

btw: Müssten nicht mit immer größerem Speicher auch die Speicheradressen länger werden?

mfG,

@Yogu: der AND-Befehl in ASM liefert bereits im Z-Flag, ob das Ergebnis False (Z) oder True (NZ) war. Problematisch wird sowas aber, wenn ein solcher Wert weiterverarbeitet werden muss (z.B. an eine andere Stelle in dem Bit-Array geschrieben werden soll).

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Hidden hat folgendes geschrieben:

btw: Müssten nicht mit immer größerem Speicher auch die Speicheradressen länger werden

Klar, das ist der Grund, warum mit mit 32-Bit auch nur auf 4GB RAM zugreifen kann (ohne Tricks zu verwenden).

Sehr erstaunliches Phänomen, das Delphi so schlampt war mir nicht bewusst.



Danach ist doch if a then eigentlich der Sonderfall oder? Man müsste also eigentlich immer if a=true then benutzen (oder eben Sorgfältig Programmieren), weil if a then sonst unerwartete Ergebnisse bringt.

// edit: @ Luckie: Dein Link geht nicht. Es wäre nett wenn du entweder deine HP nicht ganz so oft umstrukturieren würdestm, oder wenigstens Redirections setzen würdest. Leider sind viele deiner alten Posts dadurch kaum noch zu gebrauchen

Rein aus C-Sicht es ist X <> 0, was als True wahrgenommen wird. Das ist nicht nur bei C so, sondern auch das, was die CPU normal macht.

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Tilman: a ist undefiniert, weil dieser Variable ja kein Wert zugewiesen wurde. Sie enthält ganz einfach das, was vorher an dieser Adresse stand. Das ist zu einer Wahrscheinlichkeit von 1:4294967296 nicht null, also auch nicht False. Was nicht False ist, wird von Delphi als wahr angenommen.

Jetzt ist die Variable jedoch zur gleichen Wahrscheinlichkeit auch nicht -1, was der Wert der Konstante True ist. Die Variable ist also wahr, aber nicht True. Deshalb das seltsame Verhalten der ersten beiden Kontrollen. Die dritte Abfrage ist ja nur logisch, b = True. Deshalb muss da ja wohl auch das gleiche rauskommen.

Nur die letzte Abfrage macht mich stutzig: a und b, aber nicht a and b?

Wenn die Variablen einzeln abgefragt werden, kommt jedesmal ein logisches (!?) True raus, aber zusammen ergeben sie False. Das ist seltsam.

Yogu hat folgendes geschrieben:

Jetzt ist die Variable jedoch zur gleichen Wahrscheinlichkeit auch nicht -1, was der Wert der Konstante True ist.

Nein, True = 1, hat weiter oben jemand geschrieben und stimmt auch habs nachgeprüft

Yogu hat folgendes geschrieben:

Die Variable ist also wahr, aber nicht True. Deshalb das seltsame Verhalten der ersten beiden Kontrollen. Die dritte Abfrage ist ja nur logisch, b = True. Deshalb muss da ja wohl auch das gleiche rauskommen. Nur die letzte Abfrage macht mich stutzig: a und b, aber nicht a and b? Wenn die Variablen einzeln abgefragt werden, kommt jedesmal ein logisches (!?) True raus, aber zusammen ergeben sie False. Das ist seltsam.

Habs nochmal gecheckt. Der vergleich a and b ist völlig zufällig, und das lässt sich auch leicht erklären: intern werden a und b mit dem bitweisen UND verknüpft. Und weil b = 00000001 ist, a jedoch ????????, ist die Wahrscheinlichkeit eben ca. 50% dass mal True und mal False rauskommt.

Also Ergebnis: Völker, hört die Signale bzw. Compiler-Meldungen, und initialisiert eure Booleans und eine Begründung if (a) then in irgendeiner Weise if (a=true) then vorzuziehen kann ich jednefalls nicht entdecken, beides führt zu ähnlich problematischen Ergebnissen, wenn man vorher gepatzt hat.

Yogu hat folgendes geschrieben:

Die Variable ist also wahr, aber nicht True. [..] Wenn die Variablen einzeln abgefragt werden, kommt jedesmal ein logisches (!?) True raus, aber zusammen ergeben sie False. Das ist seltsam.

Das ist er, der springende Pudel Logisch ist hier nix. Es ist schlicht nicht vorgesehen dass eine Boolean-Variable einen Wert != TRUE/FALSE annimmt. Und jeder geht anders mit diesem darf-nicht-sein um: if, and, = - es gibt hier ganz offensichtlich keinen logischen Überbau. Eine Argumentation mit "ergibt WAHR aber nicht TRUE" ist daher m.E. relativer Käse, eher angebracht wäre "IF und Warheits-Operatoren ergeben im Zusammenhang mit nicht initialisierten Boolean-Variablen unvorhersehbare Ergebnisse". Denn was habe ich von ner Variable die mit IF "wahr" ergibt, die ich aber nweder mit "TRUE", noch mit anderen Booleans vergleichen darf, und die ich auch mit Operatoren wie and nicht behandeln darf - nichts. eben.

if (a) then [...] ist halt "mehr true"(tm) als if (a=true) then [...]

baka0815 hat folgendes geschrieben:

"mehr true"(tm)

True, Truer, am Truesten. (tm)


Wahr, noch wahrer, am allerwahrsten, "Chef sagt".

baka0815 hat folgendes geschrieben:

Hidden hat folgendes geschrieben: Hi, Ich glaube das <> false war mit einem lächelnden Auge Japp, war es. Ich dachte der Smiley dahinter würde ausreichen. Warum genau man einen boolschen Ausdruck nochmal auf solchen prüfen sollte, ist mir jedoch auch nicht klar. Sinn macht sowas nur, wenn man einen undefinierten Zustand braucht, also "true", "false" und "undefinded" (bzw. FileNotFound falls das wer von DailyWTF kennt ).

weshalb? es ist doch nichts undefiniert... es ist 0 = false und <> 0 ist true.. das ist doch eindeutig ... oder etwa nicht ...?

baka0815 hat folgendes geschrieben:

Hidden hat folgendes geschrieben: btw: Müssten nicht mit immer größerem Speicher auch die Speicheradressen länger werden Klar, das ist der Grund, warum mit mit 32-Bit auch nur auf 4GB RAM zugreifen kann (ohne Tricks zu verwenden).

nö ...