Daten eines Bitfeldes via for/Next nutzen

Verwende niemals Bitfields! Auch wenn man damit etwas Platzsparen kann, 
bool ist meistens schneller. Bitfields sind zum Aufbereiten Empfangener 
Daten sowie dem Speichern derselben ungeeignet. Man kann sich über die 
Reihenfolge von Bitferldern nie Sicher sein. Ich empfehle sowas:

Ungetestet:

1

#define DEC_BITS(T,ID,N) T ID[((N)+sizeof(T)*8-1)/sizeof(T)/8]

2

#define GET_BIT(ID,I) (((unsigned char*)(ID))[(I)/8]&(1<<((I)&7)))

3

#define SET_BIT(ID,I) (((unsigned char*)(ID))[(I)/8]|=(1<<((I)&7)))

4

#define UNSET_BIT(ID,I) (((unsigned char*)(ID))[(I)/8]&=(1<<((I)&7)))

5

#define SET_BIT_TO(ID,I,X) ((void)((X)?SET_BIT(ID,I):UNSET_BIT(ID,I)),(X))

6

7

struct data {

8

  DEC_BITS(uint8_t,bit,10);

9

} ReceiveBuffer;

1

for(i=0;i<10;i++){

2

  (void)SET_BIT_TO(ReceiveBuffer.bit,i,testdata[i]);

3

}

Daniel A. schrieb:
> Man kann sich über die Reihenfolge von Bitferldern nie Sicher sein.

Was verleitet Dich zu dieser Annahme?

Rufus Τ. Firefly schrieb:
> Daniel A. schrieb:
>> Man kann sich über die Reihenfolge von Bitferldern nie Sicher sein.
>
> Was verleitet Dich zu dieser Annahme?

Ich kann das nur mit K&R bestätigen. Unter anderem schreiben die beiden:

1

Almost everything about fields is implementation-dependent. 

2

Whether a field may overlap a word boundary is implementation-defined...

3

Fields are assigned left to right on some machines and right to left on others. 

4

This means that although fields are useful for maintaining internally-defined 

5

data structures, the question of which end comes first has to be carefully

6

considered when picking apart externally-defined data; 

7

programs that depend on such things are not portable.

Vergiß Bitfelder, das mögen CPUs nicht.

1

uint16_t ReceiveBuffer;

2

uint16_t val = 0;

3

for ( uint8_t i=0;i<10;i++)

4

{

5

  val <<= 1;

6

  if( testdata[i] )

7

    val |= 1;

8

}

9

ReceiveBuffer = val;

Hans Ulli Kroll schrieb:
> Daniel A. schrieb:
>> Verwende niemals Bitfields! Auch wenn man damit etwas Platzsparen kann,
>> bool ist meistens schneller. Bitfields sind zum Aufbereiten Empfangener
>> Daten sowie dem Speichern derselben ungeeignet. Man kann sich über die
>> Reihenfolge von Bitferldern nie Sicher sein. Ich empfehle sowas:
>
> irgendwie verwechselst du was ...
>
> Das mit der Reihenfolge ist wegen Little/Big Endian.

Das wurde hier bereits ausgibig besprochen:
Beitrag "Re: rechnet der preprocessor in C gcc (AVR) multiplikation aus?"
Bitordering wird nur von ABI definiert. Ich sage das nur deshalb so 
dramatisch, damit niemand auf die Idee kommt meinen Fehler zu 
wiederholen und bitfelder zum Parsen, Speichern, etc. von Daten 
verwendet. Eine andere Platform, oder ein ABI change mit einer neuen 
Compilerversion, und die Reihenfolge kann schonwieder ganz anders 
Aussehen.


> Und bei ARM gibt es effiziente Befehle zum setzen/löschen/abfragen von
> Bits.

Das mag sein, aber um diese zu nutzen ist man ja nicht zwangslaufig auf 
Bitfields angewiesen. Ich habe noch nie einen fall gesehen, in welchem 
diese einen echten Vorteil bieten. Natürlich gibt es Spezialfälle, in 
welchen diese sinvoll sind, aber die sind sehr selten.