-1

I need some help in understanding the syntax of a Bitfield definition. I read the Microsoft documentation page on it but the example there still leaves me with my question. Given a Bitfield and main method like this:

struct {
    unsigned short character : 8;
    unsigned short color     : 4;
} text[80];

int main() {
    text[20].character = 'a';
    text[20].color = 5;
}

For better reference of what I'm asking, here numbered:

  1. What do the [80] and the [20]'s mean here?
  2. Does text[80] mean an array of 80 such structs?
  3. Does text[20].character = 'a' mean, that at position 20 of the array there is a character 'a'?
TMOTTM
  • 3,286
  • 6
  • 32
  • 63
  • 3
    All of those questions look unrelated to bit fields. As in you could remove the bit fields and have the same questions. – chris Oct 31 '20 at 15:40

2 Answers2

1

"What do the [80] and the [20]'s mean here?"

text[80]; declares an array with 80 elements and text[20] accesses the 21st element.

"Does text[80] mean an array of 80 such structs?"

Yes.

"Does text[20].character = 'a' mean, that at position 20 of the array there is a character 'a'?"

Yes.

Thomas Sablik
  • 16,127
  • 7
  • 34
  • 62
1

What do the [80] and the [20]'s mean here?

The [80] means defining an array of the anonymous type that you defined(the defined structure). let me clearly tell what is happening. As unsigned short is 16 bits, this struct will be a 16 bits memory that first 8 bits are named as the character, and the 4 middle bits are named as color, and 4 ending bits are not used.

You created an array of 80 elements from this structure. It means you have 80 consecutive 16 bit in the memory; each of these elements(16 bit) has a character(8 bit) and a color(4 bit) and 4 unused bit.

Bitfield is very useful in low-level software and embedded systems. For example in your scenario, it seems a consumer waiting for data that its 8 first bits will be treated as a character(ASCII), and its 4 next bits are treated as the color of that character. So your 80 element array means 80 characters that have its own color.

SpongeBob
  • 383
  • 3
  • 16
  • _"As unsigned short is 16 bits"_ `unsigned short` has at least 2 byte. It can be larger. _"It means you have 80 consecutive 16 bit in the memory"_ that's not necessary true. The compiler is allowed to add padding. – Thomas Sablik Oct 31 '20 at 19:56
  • @ThomasSablik First, regarding unsigned short, based on the standard, you right, it will be at least 16 bit. but based on https://en.cppreference.com/w/cpp/language/types I saw that in LP32, ILP32, LLP64, LP64 implementations the size of unsigned short will be 16 bit. – SpongeBob Nov 01 '20 at 06:49
  • @ThomasSablik Second, regarding padding between array element I'm sure it is not there out of the box. Because if we had padding between array element then we couldn't able to easily convert array to pointer. Please see https://stackoverflow.com/a/1066719/10514096 – SpongeBob Nov 01 '20 at 06:52
  • _"I saw that in LP32, ILP32, LLP64, LP64 implementations the size of unsigned short will be 16 bit."_ But in other implementations it can be larger. You can have padding before `character` and between `character` and `color` – Thomas Sablik Nov 01 '20 at 10:04
  • @ThomasSablik before character maybe, but between character and color as here bitfield used, so I don't think we have any padding between these two. – SpongeBob Nov 01 '20 at 10:19
  • A compiler developer is allowed to add this padding and that would be valid behavior. A compiler developer is allowed to make `unsigned short` 8 bytes. That makes your answer wrong. – Thomas Sablik Nov 01 '20 at 10:20
  • The compiler is allowed to do it even though it doesn't make sense for you. – Thomas Sablik Nov 01 '20 at 11:40
  • @ThomasSablik First, the compiler allocates the first bitfield in 16bits(or more memory); so we have a 16bits(or more) that only the first 8 bit used and 8 ending bits(or more) are free; then the compiler tries to allocate the 'color' that is 4 bit and as it is unsigned short(the same type as the 'character'), so the compiler will store these 4 bits in the previous unsigned short.After the compiler tries to align this struct; as it is 16 bits(12 used + 4 unused) it will be aligned as 16 bits and padding will be neglected(the 4 unused bit will behave as padding) – SpongeBob Nov 01 '20 at 11:48
  • @ThomasSablik please check https://en.wikipedia.org/wiki/Data_structure_alignment and http://www.c-faq.com/struct/align.html – SpongeBob Nov 01 '20 at 11:49
  • I can't find why it shouldn't be allowed to add a padding. AFAIK it makes no sense to add padding but the compiler could do it. – Thomas Sablik Nov 01 '20 at 12:01
  • @ThomasSablik I agree with you, the compiler allowed to pad; but AFAIK, compiler padding in the data structure for alignment. If the structure is aligned, why the compiler does extra padding? (that is really unusable) – SpongeBob Nov 01 '20 at 12:05
  • Ok your answer describes a special case where `short` has 2 bytes and there is no padding. But that's not the general case. – Thomas Sablik Nov 01 '20 at 12:08
  • @ThomasSablik The title of this question is not about structure padding. It is a special case! Even if the unsigned short will be 32 or 64 bits, again it is true; Except 4 bit unused will be increased. – SpongeBob Nov 01 '20 at 12:21
  • OP didn't provide their system and compiler. You don't know if your answer is correct. It could be the one system with 16 bytes `short` and 16 bytes padding between all member variables. In that case each array element would have a size 48 bytes. – Thomas Sablik Nov 01 '20 at 12:28
  • @ThomasSablik I don't reject your opinion, because I'm not a master in all compilers! But as standard told, unsigned short should be 16,32 or 64 bit. As padding idea applied for, it came for help on alignment. So there is no reason that the compiler behaves vice and versa. – SpongeBob Nov 01 '20 at 13:04
  • _"But as standard told, unsigned short **should be** 16,32 or 64 bit"_ but it doesn't need to. _"I'm not a master in all compilers"_ You don't have to know all compilers. The standard allows it therefore your answer is compiler specific and without knowing OP's compiler your answer could be wrong. – Thomas Sablik Nov 01 '20 at 20:12