Bit fields conceptual problem

hi,

Actually , I want to ask that what is the exact use of bit fields? I have searched a lot and get one thing that they are used for saving space. But, on the other hand, I read that bits are "padded" to increase the efficieny of compiler to read/write. So, space again is utlized in that. So what is the use of using bit fields then ?

I am confused in this thing. please clear this.

thanks in advance. any help will be appreciated.

[L7Sqr]

I have found that bit fields can be useful when you want to provide a set of non-overlapping options. For example, suppose you provide a filter for the categories of things you want to output in a logging function you may set up the following:

#define LOG_DEBUG (1<<0)
#define LOG_ERROR (1<<1)
#define LOG_WARN  (1<<2)
#define LOG_MODULE1 (1<<3)
#define LOG_MODULE2 (1<<4)
//... and so on

Then, when you call the interface...

/*
 * Request logging from module 1 and debug output
 */
log_init (LOG_MODULE1 | LOG_DEBUG);

This is a little more flexible than a single log level (as an integer) but a little more verbose than an enum approach, perhaps.

[Banfa]

I would say that, particularly in portable code, the C bitfield syntax is of no use. It is a syntactic sugar for accessing bits in an integer type that can easily be achieved using the bitwise operators (& | ~ << >>) the difference is that while using the bitwise operators you can easily write portable code the C bitfield syntax is not properly portable because it is very loosely defined. Different platforms do not need to put the bits in the same order and do not have to use the same padding bits.

In general I would avoid using C bitfield syntax.

[deceptikon]

I would say that, particularly in portable code, the C bitfield syntax is of no use.

Only if you're using it to map an object or performing I/O with it. Bitfields are especially useful for flags, and in that case they're generally simpler to work with "out of the box" than bit twiddling. You can write macros to simplify the bit twiddling, but that's extra effort that may not be necessary.

[Schol-R-LEA]

To answer to OP's question, the exact use of bit fields is to allow you to pack several small values into a single integer value, by defining the values in terms of how many bits they need in order to be stored efficiently. As Deceptikon said, they are primarily useful for things like flags, which take only one bit each, or for small integer values.

The main downside to bitfields is that the exact order in which the bits are stored is compiler-dependent, as are other related issues such as the size of an int value. This means that some of the most desireable uses of them - representing the fields of an I/O port, for example - aren't portable. Now, this may actually be less of an issue than it sounds, since most of these uses are system-dependent anyway, but it does mean that anything that isn't system-specific cannot use bitfields without losing portability.

hey, Please tell me one thing. We have un-named bit fields which have width also(means not 0). So, how to access those bit fields and what is it's use. I know the use of un-named bit field having width 0, as it is needed to start from next container.

Thanks.

[deceptikon]

So, how to access those bit fields and what is it's use.

You don't access them, that's the point. They're used for padding and alignment purposes.

No, but this is the case for bit field having width zero. Where am i wrong ? If you are correct, then what is use of giving width to unnamed bit fields ?

[deceptikon]

No, but this is the case for bit field having width zero.

A zero width unnamed bitfield aligns the next bitfield to the listed type boundary rather than a programmer-specified number of bits. A non-zero width unnamed bitfield aligns the next bitfield to a programmer-specified number of bits:

/* Assuming unsigned int is 32-bits */
struct Foo {
    unsigned a: 5;
    unsigned b: 2; /* Take up 7 bits starting at the 1st bit */
    /*
        Force the next bitfield to start at the next 32-bit entity.
        This means we're skipping the remaining 25 bits of the current
        32-bit entity.
    */
    unsigned  : 0;
    unsigned c: 7; /* Take up 7 bits starting at the 1st bit */
};

/* Assuming unsigned int is 32-bits */
struct Foo {
    unsigned a: 5;
    unsigned b: 2; /* Take up 7 bits starting at the 1st bit */
    /*
        Skip the next 7 bits of the current 32-bit entity.
    */
    unsigned  : 7;
    unsigned c: 7; /* Take up 7 bits starting at the 15th bit*/
};

hey,
James Sir,

union dod
{
     int a,b;

}hello;

int main()
{
     ............
     ............
     ............

     hello.a=20;
     hello.b=20;

     printf("%d",hello.a);

     .................
     ................

     return 0;
}

What is this o/p ? It will be a garbage value or the the value of the union at that time , no matter from which field(member of union) we are accessing the union ?

please help. waiting for reply. thanks.

[deceptikon]

It's unspecified behavior if you access a member of a union that's different from the last one used to store a value. Though one of three cases can be expected:

1. The correct value will be printed.
2. A garbage value will be printed.
3. The program will blow up from a trap representation.

In the case of #1, the bytes stored in the union's memory are a valid and consistent representation of the type of the member being accessed. So in the code you posted, I would expect output of 20.

In the case of #2, there's no meaningful representation of the bytes, so you'll get a garbage value. This would be the case for storing an integer value and then trying to access it through a floating-point member:

#include <stdio.h>

int main(void)
{
    union foo { int a; double b; } foo;

    foo.a = 123;
    printf("%f\n", foo.b);

    return 0;
}

Finally, if the value when represented by the type of the accessed member is a trap representation for that type, you're screwed.

Sir,
Actually, Can you tell me what exaclty "software" topic means when any company like microsoft going to take intern test ? They said : first round will be on "aptitiude/software". So what exaclty they want to infer or ask ?

thanks a lot if you can help me in this.

[deceptikon]

I suspect it would be knowledge of Microsoft software like Visual Studio or the Office suite. By the way, that question is unrelated to this thread, and C in general. You would be better off starting a new thread in an appropriate forum.

Yes sir, I know this very well that this question is not related to C. But , I know how experienced you are. So, You are a teacher for me who can guide me in anything. So that's why i asked you. because I know you have this answer and u can answer based on your great experience.

thanks.

hey,

int a=10;

int a =10;

b= a++ + ++a ;

is this undefined or compiler-dependent ? please xplain.

thanks in advance.

[deceptikon]

It's undefined because a is being modified twice between sequence points. General best practice is to modify a variable at most one time in the statement, or even break down the statement entirely so that it always does exactly what you meant. For example, the following is much more clear as to what I wanted to happen:

int a = 10;
int b = a + (a + 1);

a += 2;

sir, actually, some times my friends says that expression like this,

b = a++ + ++a + a++ + ++a;

is compiler dependent and it executes from left to right and in compilers from right to left which is dependent on compiler.(means direction depends on compliers) are they corect ? if No, then how much they are correct?

please help!

[WaltP]

They are incorrect. Anything that is "compiler dependent" should be avoided.

As deceptikon said, it's undefined. Listen to experts, not friends.

No, No walP sir. I blindly believe on experts like u, james sir. But, Can you tell me what should i say when any body give me any expression like above to solve and say me to give the answer ? So what shoild say to them ? "this statement is undefined." is this okay ?

[WaltP]

Tell them they are wrong and do some research before giving people wrong information again.

Tell them to read this thread, and the C standard.

And don't blindly believe the experts. Sometimes even they make mistakes, or have been mislead themselves. Search for your own information and verify what you are being told.

[EDIT]
Ahh, I answered the wrong question. Yes, tell them it is undefined and you cannot tell for certain what the value will be. It may change depending on the compiler.
[/EDIT]

Can i say this that it is undefined as per C standard but it is specified for that particular compiler ? means is it specified for that complier ?

[deceptikon]

You can say that only if the compiler documents what it does. For example, some compilers support flush(stdin), but they document that support very clearly even though it's technically undefined.

It's better to simply say that the code is undefined, and thus wrong. Period.