Did the test and compiled the attached programs to assembly without any optimization flags. The result was as you said, the code for accessing the bit field was so huge that it wasn't worth it. The programs used equal CPU time though. With the -Os flag, the code generated for the bit field variant is much smaller than the code for the int variant. In return, it eats more CPU time. So I guess you were right - it's only worth it if you are a hard core minimalist counting bytes and willing to sacrifice a tiny bit of CPU time for a tiny bit of RAM. As we also want code to be readable and - as Markus pointed out - bit fields are mostly uncommon syntax except for some corner cases, it might be a better idea not to use them.
~koneu
test2.c
Description: Binary data
test1.c
Description: Binary data
On 15.07.2013, at 09:37, Roberto E. Vargas Caballero <k...@shike2.com> wrote: > > I usually use bitfields when there are a lot of items (for example > st glyph could be a good case for them). In other cases you waste > more memory with the access code that the space you save compacting > the bits in the struct. > > >> I should check generated code, but usually a mov is faster than mov+and+mov >> for setting a bit. >> >> On Jul 14, 2013, at 23:22, Markus Teich <markus.te...@stusta.mhn.de> wrote: >> >>> Since this is just uncommon syntax (at least I haven't seen it before) and >>> it is just used in the declaration I would be ok with it, if an additional >>> comment explains it. It's not a strong opinion though, just an idea. > > > -- > Roberto E. Vargas Caballero > ---------------------------- > k...@shike2.com > http://www.shike2.com >
