BOOL - Eine Frage der Ästhetik?
-
der mann hieß aber boole- warum heißt dann der variablentyp nur bool?
-
groovemaster schrieb:
Die würden das wohl nicht machen, wenn's langsamer wäre.
Die mache noch viel schlimmeres.
-
Und das wäre...
-
scrub schrieb:
der mann hieß aber boole- warum heißt dann der variablentyp nur bool?
ein Seitenhieb auf creat
-
groovemaster schrieb:
Und das wäre...
http://www.c-plusplus.net/forum/viewtopic.php?t=78632
MfG SideWinder
-
Und weil MS in der MFC compilerspezifische Dinge (vom eigenen Compiler!) benutzt, implementieren sie bool langsam?
-
Bei 32-Bit Operationen mit 8Bit Werten werden die restlichen 24Bit doch extra aufgefüllt, daraus hab ich einfach mal geschlossen, dass ein 32Bit Wert schneller als nen 8Bit Wert mit einer 32Bit CPU verarbeitet werden kann.
Außerdem meine ich sowas auch im "Das Assembler Handbuch (Addison&Wesley)" gelesen zu haben.Aber da man ein bool ja sogar mit einem Bit darstellen kann, wären 32Bit ja auch übertrieben (man verwendet ja auch nicht 32Bit für nen char).
-
groovemaster schrieb:
Und das wäre...
managed C++ ????
-
SirLant schrieb:
Bei 32-Bit Operationen mit 8Bit Werten werden die restlichen 24Bit doch extra aufgefüllt, daraus hab ich einfach mal geschlossen, dass ein 32Bit Wert schneller als nen 8Bit Wert mit einer 32Bit CPU verarbeitet werden kann.
Hardware arbeitet aber parallel, das auffüllen kostet daher nicht unbedingt Zeit.
-
SirLant schrieb:
Bei 32-Bit Operationen mit 8Bit Werten werden die restlichen 24Bit doch extra aufgefüllt, daraus hab ich einfach mal geschlossen, dass ein 32Bit Wert schneller als nen 8Bit Wert mit einer 32Bit CPU verarbeitet werden kann
Ne, das ist nicht so. Man arbeitet dann halt einfach mit al, anstatt mit eax. Und ein movzx ist heutzutage afaik genauso schnell wie ein mov (aber das driftet jetzt schon wieder zu sehr in die IA32 Assembler Programmierung ab).
@SideWinder
Dein Link ist ja schön und gut, aber der C++ Standard (jaja ich weiss, wir sind im C Forum) besagt, dass die Verwendung eines dereferenzierten Nullzeigers UB gibt. Und das bedeutet, es kann alles passieren, sogar dass das Programm einwandfrei funktioniert. Ich wüsste also nicht, warum sich hier der MSC "schlimm" verhalten soll. Es ist deine eigene Schuld, wenn du sowas machst.
(Wenn du was anderes gemeint hast, dann sag es nochmal explizit. Ich hatte gerade keine Lust, mir den ganzen Thread durchzulesen).ZuK schrieb:
managed C++ ????
Du bist dir selbst nicht sicher und wirfst dann so tolle Kommentare in die Runde? Managed C++ hat nix mit Standard C++ zu tun. Und niemand zwingt dich das zu benutzen. Du kannst mit dem MSC (fast) astreine ISO C/C++ Programme schreiben. Du wirst jedenfalls nicht gezwungen etwas zu benutzen, dass nicht standardkonform ist. Managed C++ wurde entwickelt, um den GUI Bedürfnissen von .NET unter C++ gerecht zu werden, da Standard C++ in dieser Beziehung etwas "unterentwickelt" ist. Ob Managed C++ nun ein gutes Design hat, darüber kann man streiten, steht hier aber nicht zur Diskussion. Es ist einfach nicht mehr und nicht weniger als eine Compilererweiterung. Zudem sind wir im C Forum und allein deswegen ist Managed C++ für mich kein Argument. Noch irgendwelche andere Vorschläge?
-
Als ich mich das letzte Mal mit x86 - Assembler-Optimierung befaßt habe (ok, ist eine Weile her, PIII war da gerade neu...), waren 8bit- und 32-bit-Daten gleichwertig (Speicherzugriff, Operationen bei gleichbleibender Größe, Stalling etc.) 16-bit war aber deutlich "gebremst".
Und bei einem einzelnen Byte hast du nie ein falsches alignment