Bitfelder, warum implementierungsspezifisch?

C/C++ - Bitfelder scheinen eine große Anwendung in Hardwaretreibern und binären Netzwerkübertragungen zu haben. Sie scheinen jedoch nicht weit verbreitet zu sein und werden allgemein davon abgeraten, da das tatsächliche binäre Layout implementierungsspezifisch ist, wie in diesem Zitat aus dem C99-Standard 6.7.2.1/10 - "Struktur- und Gewerkschaftsspezifizierer" zu sehen ist;Bitfelder, warum implementierungsspezifisch?

Eine Implementierung kann jede adressierbare Speichereinheit zuweisen, die groß genug ist, um ein Bitfeld aufzunehmen. Wenn genügend Speicherplatz vorhanden ist, sollte ein Bitfeld, das unmittelbar einem anderen Bitfeld in einer Struktur folgt, in benachbarte Bits derselben Einheit gepackt werden. Wenn nicht genügend Speicherplatz vorhanden ist, wird die Implementierung definiert, ob ein Bitfeld, das nicht in die nächste Einheit passt oder benachbarte Einheiten überlappt. Die Reihenfolge der Zuordnung von Bitfeldern innerhalb einer Einheit (höher zu niedrig oder niedrig zu hoch) ist implementierungsdefiniert. Die Ausrichtung der adressierbaren Speichereinheit ist nicht spezifiziert.

Meine Frage ist ziemlich einfach; Warum hat das Komitee entschieden, Bitfelder als etwas Implementierungsspezifisches zu belassen und es dadurch zu einem Compilerkonstrukt zu machen, das hauptsächlich für eine reduzierte Speichernutzung verwendet werden kann, wo es in vielen Fällen verwendet werden könnte, um schöne Binärlayouts bereitzustellen, und frei Entwickler aus Bit-Gauner-Code?

Quelle

2013-07-18 Skeen

Ich kann mir einige Gründe vorstellen ... Endianness kommt mir in den Sinn. Aber auch wenn ein Bitfeld teilweise in ein und teilweise in ein anderes Byte gesetzt würde, hätte dies eine Auswirkung auf die Leistung, so dass das Komitee entschied, dass Compiler frei entscheiden können, wie es zu tun ist, vielleicht basierend auf Benutzereinstellungen für Geschwindigkeits- oder Größenoptimierung. –

Ich bin sicher, dass die Tatsache, dass die Anzahl der Bits pro Byte nicht 8 sein muss, auch etwas damit zu tun hat. –

@Mr Lister: Um sicherzustellen, dass ein Feld im nächsten Byte ausgerichtet ist und daher nicht in der Mitte eines Bytes beginnt, erhalten wir das Null-Bit-Feld, richtig? - Das ist schon im Standard. – Skeen

Aus dem gleichen Grund, so viele andere Dinge sind nicht streng durch den Standard spezifiziert: Um Flexibilität zu ermöglichen, einen Compiler für eine große Anzahl von Plattformen und Systemen zu produzieren, und immer noch einen EFFICIENT Compiler.

Insbesondere Bitfelder, die in einer bestimmten Bit/Byte-Reihenfolge gespeichert werden müssen, würden es schrecklich langsam auf Maschinen machen, deren natürliche Byte-Reihenfolge der "falsche Weg" ist.

Ja, es bedeutet, dass es ein richtiger Schmerz im Hintergrund ist, Bitfelder über mehrere Architekturen und Plattformen hinweg portierbar zu machen. Wenn Sie das wirklich brauchen, dann sollten Sie vielleicht eine andere Lösung in Betracht ziehen ...

Quelle

2013-07-18 12:48:03

Also, zumindest in meiner Welt, bedeutet dies, um eine möglicherweise langsame Funktion zu vermeiden, sie mit einer meist unbenutzbaren Funktion? – Skeen

Nein, es ist perfekt verwendbar, solange Sie es nicht auch brauchen, dass es wirklich tragbar ist. Beachten Sie, dass bei vielen Architekturen der Hauptunterschied in der Byte-Reihenfolge und nicht in der Bit-Reihenfolge liegt. Sie sind also in Ordnung, solange der Prozessor identisch ist. Und ich bin mir sicher, dass die meisten Leute sich zumindest genauso laut beschwerten würden, wenn es nicht effizient wäre (aber perfekt tragbar und gut definiert). –

Sie haben wahrscheinlich recht, obwohl ich lieber ein tragbares, gut definiertes Bitfeld haben möchte, und dann selbst das bisschen fummeln, wann immer ich Leistung brauche. Als umgekehrt. – Skeen

Bitfelder, warum implementierungsspezifisch?

Antwort

Verwandte Themen