Hallo Claus,
Wie der Compiler diese Daten ablegt, ist seine Sache.
das will ich nicht hoffen. Schließlich muss die Struktur-Deklaration beispielsweise zu einem Hardware-Interface (z.B. einem memory-mapped I/O-Port) passen, wenn ich auf Hardware- und Treiberebene arbeite. Denn das ist wohl der hauptsächliche Anwendungsbereich für solche Bit-Felder.
Insbesondere sollte man nicht durch das Addieren von Bytes meinen, die Größe einer Struktur zu kennen, da Strukturen (und auch die Daten innerhalb einer Struktur) gerne an Grenzen ausgerichtet werden, die für einen schnellen Zugriff günstig sind.
Wenn ich einen modernen Compiler entsprechend dazu anweise, tut er das tatsächlich. Aber ebenso kann ich ihn durch geeignete Direktiven anweisen, auf dieses Alignment zu verzichten und stattdessen alles dicht an dicht zu packen. Das ist meine bevorzugte Einstellung, weil ich normalerweise maximale Kontrolle über den Programmcode haben will. Wenn ich die Daten wirklich zugriffsoptimiert ausrichten will, mache ich das an der Stelle, wo es sein soll, explizit (notfalls, wenn der Compiler das nicht besser kann, wieder durch Auszählen und Auffüllen mit Dummy-Bytes).
Bei die 16-Bit Prozessoren ist es oft effizienter Strukturen und auch Daten innerhalb einer Struktur an einer geraden Adresse beginnen zu lassen. Für die 32-Bitter gilt ähnliches für durch 4 teilbare Adressen. Entsprechendes gilt für andere Architekturen.
ACK. Wobei das bei den meisten CPUs nur dann eine Rolle spielt, wenn bei einem Zugriff eine entsprechende z.B. durch 4 teilbare Adresse _überschritten_ wird. Liegt ein kleineres Element (z.B. WORD) _innerhalb_ eines DWORD-optimierten Adressfensters, hat das normalerweise keine Nachteile, auch wenn dieses Element nicht exakt auf eine durch 4 teilbare Adresse ausgerichtet ist.
Schönes Wochenende,
Martin
Das Gehirn ist schon eine tolle Sache: Es fängt ganz von allein an zu arbeiten, wenn man morgens aufsteht, und hört erst damit auf, wenn man in der Schule ankommt.
(alte Schülererkenntnis)