[aside]Originally Posted by Hunter2
I had a complier decide that when I said unsigned int for a bitfield that I meant it. And it chose that minimum size for the containing struct -- which was twice as big as I wanted. I had to use the nonstandard unsigned char to tell it to use a smaller type.
[/aside]
I don't think it is forced, I believe it is one of those implementor's descretion type of things. (The DWIM instruction.)
7. It is easier to write an incorrect program than understand a correct one.
40. There are two ways to write error-free programs; only the third one works.*
>>but in a word, speed.
Odd, I thought bitfields conceptually lend themselves better to the "trade speed for memory" end of the spectrum. If that's the case then, bitfields seem to be a waste of both speed and memory
@Dave: Interesting read
Just Google It. √
(\ /)
( . .)
c(")(") This is bunny. Copy and paste bunny into your signature to help him gain world domination.
> Right, but why is it forced to 32 bits (as opposed to 8), or is that a typo?
Because that's what your compiler writer decided was the best thing to do.
If you have a lot of bit fields, the best the compiler can do is pick the biggest supported underlying data type (say unsigned long), and pack as many bitfields as possible into that.
Now if you want to try and reduce that, say to force type:5 and locale:1 into just one byte, then you might try your compiler specific
#pragma pack(1)
or in gcc, something like attribute((__packed__))
> "trade speed for memory" end of the spectrum.
Try some "gcc -S" experiments to see what sort of asm code is generated.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
Depends onthe compiler. Bitfields are implementation specific. I believe there's a post around here some place where a bunch of us did some bitfield stuff, and MSVC++ had a horrible implementation of them, which turned out far slower results than the rest of them.>>but in a word, speed.
Odd, I thought bitfields conceptually lend themselves better to the "trade speed for memory" end of the spectrum. If that's the case then, bitfields seem to be a waste of both speed and memory
@Dave: Interesting read
Quzah.
Hope is the first step on the road to disappointment.
>>the best the compiler can do is pick the biggest supported underlying data type (say unsigned long), and pack as many bitfields as possible into that.
Oh, I thought you meant that each bitfield was forced to 32 bits (i.e. the bitfield sizes are ignored, ->). Makes more sense now.
Just Google It. √
(\ /)
( . .)
c(")(") This is bunny. Copy and paste bunny into your signature to help him gain world domination.
