TRUE oder true?
-
Das Idiom um int-Bools auf den Wertebereich {0, 1} einzuschränken ist übrigens !!x
-
Dass das alles funktioniert weiß ich schon, aber warum sollte man int-bools statt bools verwenden?
(Das interessiert mich wirklich schon lange, vielleicht könnt Ihr mich ja aufklären: Warum existiert so etwas wie BOOL überhaupt?
)[ Dieser Beitrag wurde am 18.02.2003 um 21:05 Uhr von nman editiert. ]
-
weil es bei Maschinen das Binäre System gibt (1 und 0) außerdem kennste doch bestimmt aus dem Matheunterricht "Boolonische Opperatoren" oder so? (weis net mehr genau, is schon paar Jahre her)
-
bool gibts in C++ noch nicht so lange, da ist es naheliegend für größere Bibliotheken, sich eigene boolsche Typen zu definieren. Heute haben wir bool, sogar in C, aber davon gehen die alten BOOLs ja nicht weg
-
BOOL ist einfach nur veraltet, genauso wie die c-winapi funktionen.
Meiner Meinung sollte amn bool benutzen, für was hat man es denn wohl erfunden. Aber im Endeffekt ist es dann doch meistens scheiß egal.
Sollte liber woanders optimieren denke ich.
-
Original erstellt von Ikari:
weil es bei Maschinen das Binäre System gibt (1 und 0) außerdem kennste doch bestimmt aus dem Matheunterricht "Boolonische Opperatoren" oder so? (weis net mehr genau, is schon paar Jahre her)Eben - warum sollte man dann BOOL statt bool verwenden? Ist doch Blödsinn!
Du meinst "Boole'sche"...Bashar: Auch das ist mir klar, aber letztlich sind das nur historische Hintergründe - was mich interessieren würde ist, warum nach wie vor am obsoleten BOOL festgehalten wird.
-
Achso. Keine Ahnung, ich kenne niemanden der daran festhält.
-
Wenn man in WinApi programiert hält man daran fest.
-
BOOL ist eventuell schneller als bool...der rechner mag 4bytes lieber als 1 byte
-
was hat das thema eigentlich speziell mit spiele und grafik-programmierung zu tun?
-
Vielleicht sind aber auch die schnuckligen kleinen bools schneller, weil davon mehr in den Cache passen tun...
MfG Jester
-
ich habs mal ausprobiert, was schneller is:
bool!
bei nem test mit ner schleife die ne million mal durchläuft und dann paar bools oder BOOLs anlegt und ein bißchen mit rummacht (Zuweisung etc.) war bool rund doppelt so schnell
-
Original erstellt von crass:
BOOL ist eventuell schneller als bool...der rechner mag 4bytes lieber als 1 byteWer hat diesen Quatsch eigentlich in Umlauf gebracht?
-
Original erstellt von Bashar:
Wer hat diesen Quatsch eigentlich in Umlauf gebracht?Soweit ich weiß, ist das kein Quatsch. Wir haben es mit 32-Bit-Prozessoren zu tun. Rechnen mit Bytes erfordert eine Konvertierung von Byte nach DWORD, dann die Berechnung, und anschließend wieder zurückkonvertieren (so steht's jedenfalls in "Inside DirectX"). Außerdem hat der Pentium4-Prozessor es gern, wenn Variablen in 16-Byte-Blöcken angeordnet sind. Darum gibt es ja bei DirectX 9 z.B. die Klasse D3DXMATRIX16 (oder "A16"?).
-
wieso quatsch? pentium-prozessoren rechnen eben mit 32bit am liebsten
-
Bashar hat eigentlich immer Recht mit seinen Aussagen, deswegen bin ich gespannt auf seine Begründung.
-
Original erstellt von TomasRiker:
Soweit ich weiß, ist das kein Quatsch. Wir haben es mit 32-Bit-Prozessoren zu tun. Rechnen mit Bytes erfordert eine Konvertierung von Byte nach DWORD, dann die Berechnung, und anschließend wieder zurückkonvertieren (so steht's jedenfalls in "Inside DirectX"). Außerdem hat der Pentium4-Prozessor es gern, wenn Variablen in 16-Byte-Blöcken angeordnet sind. Darum gibt es ja bei DirectX 9 z.B. die Klasse D3DXMATRIX16 (oder "A16"?).klar nimmt der prozessor immer schöne stücke - aber stell dir mal ne schleife vor - da kann er glatt 4 bools nehmen während er nur 1 BOOL bekommt.
der compiler ist schon klug genug zu optimieren, und er macht aus 1 Byte wenn er es für richtig hält 4 byte (zur compile time) und wenn er denkt dass es nicht gut ist, dann lässt er 1 byte.
das ist doch auch der grund warum man sagt:
builitin by value übergeben und nicht per const reference - weils per value schneller ist -> der compiler kann optimieren wie und wo er will.
-
Original erstellt von TomasRiker:
Rechnen mit Bytes erfordert eine Konvertierung von Byte nach DWORD, dann die Berechnung, und anschließend wieder zurückkonvertieren (so steht's jedenfalls in "Inside DirectX").wird durch meine Erfahrung nicht bestätigt. Die Addition zweiter chars wird im gcc durch eine Byte-Addition dargestellt. Was du sagst, stimmt dann, wenn in dem Ausdruck auch ints vorkommen.
Ausserdem wird mit bool nicht gerechnet ...Der Vorteil mag nicht mal annähernd 1:4 sein, aber gleich einen Nachteil aus !Dword zu zimmern ist übertrieben.
-
der compiler ist schon klug genug zu optimieren, und er macht aus 1 Byte wenn er es für richtig hält 4 byte (zur compile time) und wenn er denkt dass es nicht gut ist, dann lässt er 1 byte.Man sollte sich nicht immer auf die optimierungen des compilers verlassen.
Wenn man eine Var zum Rechnen braucht nimmt man eben int weil man weiß dem Rechner schmeckts am Besten. Zu sagen, ich nehm BYTE , der Compiler wirds schon richten, is net unbedingt die richtige Einstellung..Ich habs grad mal getestet..BYTE gegen int: ohne Optimierung war int deutlich schneller, mit Optimierung gleich
[ Dieser Beitrag wurde am 19.02.2003 um 14:19 Uhr von crass editiert. ]
-
Original erstellt von crass:
Man sollte sich nicht immer auf die optimierungen des compilers verlassen.
Wenn man eine Var zum Rechnen braucht nimmt man eben int weil man weiß dem Rechner schmeckts am Besten. Zu sagen, ich nehm BYTE , der Compiler wirds schon richten, is net unbedingt die richtige Einstellung..Diese Einstellung ist Blödsinn.
Der Compiler kann nicht alles richten, aber wenn man schreibt was man meint statt zu schreiben, was Compiler vor 10 Jahren zu besserem Assembly-Code verwursten konnten, wird das schnell ins Auge gehen.Du kritisierst: Verlasst Euch nicht darauf, dass Euer Compiler optimiert! und machst es so jedem optimierenden Compiler schwer, weil Du voraussetzt, dass ein Compiler so dumm sein muss, dass er nicht erkennt wie das Byte-Alignment günstigerweise auszusehen haben sollte. Schreibe keine Programme für bestimmte Compiler sondern welche für eine bestimmte Sprache!
Performance gewinnt man nicht durch BOOLS und Byteshifts sondern durch performante Algorithmen, gut designte Datenstrukturen/ Klassen und Code in dem Du schreibst, was Du machen möchtest und nicht irgendwelche Spielereien aus vermodernden Optimierungskisten (Besser wartbar werden Deine Programme dadurch obendrein)!