# Bit Fields

This topic is 4684 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I just recently re-discovered bit fields. For those of you who do not know what bit fields are, here is a small explaination: a bit can have 2 states, (0 or 1). The idea is that for something that has states, to use bit fields to save space. Why use an integer or a char for something that has only two states, when all you really need is a bit? Simply use it like such: unsigned int name:1; That would simply create a bit in memory. name would only be able to be assigned the values 0 or 1, because those are the only values that can be created using 1 bit. If we had done: unsigned int name:4; Then we would have been able to assign anywhere between 0 and 15. So my question is, besides the fact that bit fields often make code a little dirty, why do I see them so rarely? I suppose #defines could make code legible, and I would think that with their space saving ability, they would be more widely used...especially in network programming. Anyone use these buggers? Any thoughts on effective usage? -visage

##### Share on other sites
I'd say that's because unless you're talking to hardware or are direly constrained in memory, there is little need to bother with them. Plus, they're not magic: it all compiles down to ands, ors and bitshifts anyway.

Finally, many people don't even know they exist... chalk that one up to education.

##### Share on other sites
Quote:
 Original post by FrunyPlus, they're not magic: it all compiles down to ands, ors and bitshifts anyway.

Well, I understand that, but if a char is 8 bits, and you only need 1, that seems to be a lot of space you are saving -- especially with network data and message based systems.

Maybe they make more sense on consoles and mobile units, where memory is not nearly as abundant as it is on PCs.

##### Share on other sites
Just coded some tonight; and now I read this post.. heh , the coincedence.
I use them to store a range of Boolean values; 1 byte can store 8 values.
Very handy. I use bytes and bits all the time to store any info.

##### Share on other sites
Now, a downside is that you cannot take a pointer or a reference to a bitfield member. Which is why std::vector<bool> is so broken.

struct foo{   char a : 1;   char b : 1;   char c : 6;};int main(){   int foo::*ptr = &foo::a;}foo.cc: In function 'int main()':foo.cc:10: error: invalid pointer to bit-field 'foo::a'

##### Share on other sites
Quote:
 Original post by visageWell, I understand that, but if a char is 8 bits, and you only need 1, that seems to be a lot of space you are saving -- especially with network data and message based systems.

Nope. If you just declare a single bit, it'll still allocate a byte. Which means you're using just as much memory.

I used to use them when I needed multiple flags, but I've since stopped. I don't really have a reason.

CM

##### Share on other sites
Conner, you are such a stickler, though you are right. Bit fields are only effective when used several at a time, or you are just wasting space. Though, I still see the ability to have essentially 8 bools packed into 1 byte fairly useful...

Fruny, why is that?

##### Share on other sites
Quote:
 Original post by FrunyFinally, many people don't even know they exist... chalk that one up to education.

Bingo! I know I'd never seen them until I was reading a Real Time Strategy Game Programming book. I was like what the heck are the colons doing [lol]. However though, education fails to teach a lot of things about C++...

##### Share on other sites
Quote:
 Original post by visagewhy is that?

Because pointers don't have the resolution to reference individual bits.

##### Share on other sites
A lot of space can be saved this way if we're talking about network applications, and when we're talking about cutting down on traffic. But if we're talking about an word processor, a browser, image editor, games, it really isn't worth it because of the insignificant amount of space we're talking about compared with today's memory capacity and the memory alignment issue, that will slow down the write and read operations on those values.

##### Share on other sites
It could speed-up the reads & write if it compacts your data to fit in a register or within a cache line, though even cache lines are huge today.

A more pressing issue with bit-fields, is that the assembly they emit tends to be sub-optimal compared to just masking the bit on or off. Most of the time you know a priori if you want the bit on or off, so you can just code it reg |= 1<<bit; or reg &= ~(1<<bit);

So when you're fiddling hardware registers, where bit-fields appear to be quite useful, you tend not to use them to save a few cycles (or even a stall if the emitted code branches!).

If you look at the linux socket stack (and I imagine bsd et. al. as well) you'll see them using bit-fields in a number of structure definitions.

Are bit-fields portable? I forget how they handle endianness? Are they always msb (or lsb) first?

##### Share on other sites
Just to add to what's been said, something I found interesting:

Quote:
 Original quote by: Bjarne Stroustrup, "The C++ Programming Language: Special Edition"Suprisingly, using fields to pack several variables into a single byte does not necessarily save space. It saves data space, but the size of the code needed to manipulate these variables increases on most machines. Programs have been known to shrink significantly when binary variables were converted from bit fields to characters! Furthermore, it is typically much faster to access a char or an int than to access a field. Fields are simply a convenient shorthand for using bitwise logical operators...

##### Share on other sites
Programming for something like a GameBoy, your executable code is stored in ROM, of which you get a fairly large amount of, up to 8MB. There is however a very limited amount of RAM, only 16KB, half of which is used for 'video memory', so saving some memory at the expense of needing more code use it could be useful.