sizeof auf bit fields

Barade

struct TilepointData
{
	uint16_t groundHeight;
	unsigned int boundaryFlag:1;
	unsigned int waterLevel:15;
	unsigned int flags:4;
	unsigned int groundTextureType:4;
	uint8_t textureDetails;
	unsigned int cliffTextureType:4;
	unsigned int layerHeight:4;
};

sizeof(struct TilepointData) // liefert 8 und nicht 7

Liegt das an der genannten compiler- bzw. architekturspezifischen Implementation von bit fields oder woran?

Des Weiteren wollte ich allgemein mal fragen, ob man bit fields eher meiden sollte. Im obrigen Fall lohnt es sich für mich, da viele Werter kleiner als 1 Byte sind.

könnte sein das es am padding liegt, welches eingefügt wird um die performance zu erhöhen, solange die struct nur innerhalb deiner software verwendet wird ist das so schon ok, anders sieht es aus, wenn damit daten mit anderer software(protokollen) ausgetauscht werden soll, da dann nicht sichergestellt ist, das die werte stimmen.

http://en.wikipedia.org/wiki/Data_structure_alignment

lg lolo

lustig

Der Compiler füllt normalerweise immer nur die Bits eines Typs auf.

struct TilepointData
{
    uint16_t groundHeight;
    unsigned int boundaryFlag:1;
    unsigned int waterLevel:15;
    unsigned int flags:4;
    unsigned int groundTextureType:4; // 24/32 bits belegt
    uint8_t textureDetails;           // neuer Datentyp -> wird nicht in den uint geschrieben
    unsigned int cliffTextureType:4;
    unsigned int layerHeight:4;
};

Versuch mal das:

struct TilepointData
{
    uint16_t groundHeight;
    unsigned int boundaryFlag:1;
    unsigned int waterLevel:15;
    unsigned int flags:4;
    unsigned int groundTextureType:4;
    unsigned int cliffTextureType:4;
    unsigned int layerHeight:4;
    uint8_t textureDetails;
};

sizeof(struct TilepointData)

volkard

lustig schrieb:

Der Compiler füllt normalerweise immer nur die Bits eines Typs auf.

struct TilepointData
{
    uint16_t groundHeight;
    unsigned int boundaryFlag:1;
    unsigned int waterLevel:15;
    unsigned int flags:4;
    unsigned int groundTextureType:4; // 24/32 bits belegt
    uint8_t textureDetails;           // neuer Datentyp -> wird nicht in den uint geschrieben
    unsigned int cliffTextureType:4;
    unsigned int layerHeight:4;
};

Versuch mal das:

struct TilepointData
{
    uint16_t groundHeight;
    unsigned int boundaryFlag:1;
    unsigned int waterLevel:15;
    unsigned int flags:4;
    unsigned int groundTextureType:4;
    unsigned int cliffTextureType:4;
    unsigned int layerHeight:4;
    uint8_t textureDetails;
};

sizeof(struct TilepointData)

Nette Idee.
Und dann gleich noch das

struct TilepointData
{
    unsigned int boundaryFlag:1;
    unsigned int waterLevel:15;
    unsigned int flags:4;
    unsigned int groundTextureType:4;
    unsigned int cliffTextureType:4;
    unsigned int layerHeight:4;
    uint16_t groundHeight;
    uint8_t textureDetails;
};

sizeof(struct TilepointData)

volkard

Barade schrieb:

Des Weiteren wollte ich allgemein mal fragen, ob man bit fields eher meiden sollte. Im obrigen Fall lohnt es sich für mich, da viele Werter kleiner als 1 Byte sind.

Normalerweise erkauft man sich mit dem Packen der Daten meßbare bis störende Laufzeiteinbußen. Ich kenne nur wenige Ausnahmen, wie http://uo.stratics.com/heptazane/fileformats.shtml#2.0 , wo ich den Entwicklern glaube, daß sie nachgemessen haben. Aber dort ging es wohl darum, möglichst viele der Daten überhaupt ind RAM zu kriegen, für einen gesparten Plattenzugriff kann man viele tausend bitshifts opfern.