Hi Ralf,
From: "Ralf Corsepius"
Am Sam, 2003-05-17 um 16.23 schrieb Andre Heine: [...]
Im C Buch von Suse Press steht, das Bitfelder langsamer sind, weil diese intern "shiften", bit Verknüpfungen(& |) sollen sehr performant sein, aber nicht speicherefffizient wie Bitfelder... So pauschal ausgedrückt, ist diese Aussage falsch. Die Effizienz von C-Bitfeldern ist sehr compiler- und prozessorabhängig. Das Ergebnis kann je nach Anwendung, Compiler und Prozessor sehr unterschiedlich ausfallen.
Das stimmt, Bits können je nach Prozessor/ Compiler anders angeordnet sein. Aber wenn ich ein Bitfeld habe, wo ich "union.bittyp.bit0 = 1" setze, muss das ist immer so sein! Ich meine, es ist egal das der Compiler das nun rechts oder links anordnet. bit0 im struct ist immer '1'. In meinen Beispiel benutze ich in einer "union" eine "unsigned char" mit einem Bitfeld, d.h, wenn nun der Compiler die Bits anders für das "unsigned char" anordnet, ist das natürlich fatal, weil eben die Reihenfolge anders ist. Das wird ein BUG im Programm, den ich nicht gerne suchen möchte :))) ( Wer denkt sofort an die Bitausrichtung, na gut Ralf schon *Grins* ) [...]
Meine Vorliebe liegt bei den Bitfeldern, lässt sich im Quelltext viel besser lesen. Grösster Nachteil von C-Bitfeldern: Die interne Reihenfolge der Bits innerhalb von structs ist nicht definiert. D.h. so bald C-Bitfelder binär ausgegeben werden sollen oder Hardware mit Bitfeldern angesteuert werden sollen, wird der Code unportabel.
Das habe ich, ehrlich gesagt, gar nicht bedacht... Da brauche ich eigentlich nur die vorhandenen Bitfelder "umdrehen" und schon sollte mein Code immernoch lesbar sein und auch dieses manko beheben. Mit defines kann man das ja Konfigurieren, welche bitfelder genommen werden, je nach Prozessor ... Ciao andre