1. ## bitwise help

I am reading a book on this stuff right now and I just don't get this one part could ya'll help me plz. I understand as much as this.
Code:
```struct info{
int x:1;
int y:1;
};```
Now doesn't that creat two variables that can only hold a value of 1 or 0 right. They did it with bigger numbers like 14 and they started doiing bitwise "setting" with the | operator. And they got the negation of it. Could someone help me understand and find a practical use for this plz??

2. Search the board for "bitfields", "masks", "bit manipulation", etc. The basic idea is that you can save space by using individual bits to store/retrieve data. For instance, let's say you have to grade a test that has 32 questions. You could use 32 integers (128 bytes) to score each answer as wrong/right, *or* you could use the 32 bits of a single integer (4 bytes) to store the results. Without bitfields, you have to manipulate bits using logical bit operations. Otherwise, you can manipulate the bits as if they were ordinary members of a struct.

3. Code:
```struct info{
int x:1;
int y:1;
};```
Single bit bit-fields should be declared as unsigned int to ensure either 0 or 1 as valid values. Most of the time such a bit-field is to be used as a binary flag, and having 1 as an invalid value would definitely cause problems.

>Now doesn't that creat two variables that can only hold a value of 1 or 0 right.
Not necessarily, but if you make them unsigned, yes that is correct.

>Could someone help me understand and find a practical use for this plz??
Bit-fields can be easier that regular bit twiddling:
Code:
```struct {
unsigned good :1;
unsigned fail :1;
} flags;

if ( flags.good == 1 ) /* Easy test */

flags.fail = 1; /* Easy set */
flags.good = 0; /* Easy unset */```
Compare that to the use of an int variable and bit operations:
Code:
```unsigned flags = 0;

if ( ( flags & ( 1U << 1 ) ) == 1 ) /* Not so transparent test */

flags |= ( 1U << 0 ); /* Not so transparent set */
flags &= ~( 1U << 1 ); /* Not so transparent unset */```
Of course, bit-fields are 100% non-portable whereas bit twiddling can be made to be portable. Most programmers choose to have the extra flexability and decreased clarity over ease of use, clarity, and no portability.

4. >> Of course, bit-fields are 100% non-portable...

I didn't know that. I thought they were part of the language?

5. >I thought they were part of the language?
They are, but the standard specifies very little about the actual layout by a compiler. To quote K&R:
Almost everything about fields is implementation-dependent. Whether a field may overlap a word boundary is implementation-defined. Fields need not be named; unnamed fields (a colon and width only) are used for padding. The special width 0 may be used to force alignment at the next word boundary.

Fields are assigned left to right on some machines and right to left on others. This means that although fields are useful for maintaining internally-defined data structures, the question of which end comes first has to be carefully considered when picking apart externally-defined data; programs that depend on such things are not portable. Fields may be declared only as ints; for portability, specify signed or unsigned explicitly. They are not arrays, and tehy do not have addresses, so the & operator cannot be applied to them.

6. Thanks for clearing that up, Prelude.

Too bad that didn't get standardized, anyway....

7. Do you have to have a certain type for certain variables? For example could you have an int with a bitfeild of 16 because a int can hold up to 16 bits could you have an int with 17 ex
Code:
```struct outline{
unsigned int x:17;
unsigned int y:16;
} blah;```
Would the variable x work?

8. Originally posted by linuxdude
Do you have to have a certain type for certain variables? For example could you have an int with a bitfeild of 16 because a int can hold up to 16 bits could you have an int with 17 ex
Code:
```struct outline{
unsigned int x:17;
unsigned int y:16;
} blah;```
Would the variable x work?
Kind of. You can't exceed the number of bits in a given type. If you're on a compiler with 16 bit integers, then no, you can't have a 17 bit integer. If you have 32bit integers, sure, go for it.

Let's say I have a paint store, and I only have the primary colors of paint: red, blue, yellow.

I dont need to have a whole integer, so I limit myself to two single bits, and use the rest of the space for something else, like a sale price or whatever.
Code:
```struct paint
{
unsigned int color:2;
...other stuff...
};```
Now then, when I have a new order, color is set to 0, meaning they haven't picked one. When they pick one, we have the following:
Code:
```switch( yourorder.color )
{
case 1: /* red */
break;

case 2: /* blue */
break;

case 3: /* yellow */
break;

case 4: /* will never exist, strictly here to show the point that it can't exist and won't */
break;

case 0: /* no color selected */
break;
}```
So the answer is yes, but you can't have a variable with more bits than the type itself.

Quzah.

9. >because a int can hold up to 16 bits
Unwarranted assumption, an int can be at least 16 bits. Because of this, C places no limit on the size of a bit-field. However, you can't have a bit-field that exceeds the number of bits in a given type. In this case, signed int, unsigned int, _Bool for C99, or an implementation-defined type.