...but not for the reasons you state.

One of the best uses for bit fields is setting/getting hardware registers that have an annoying tendency to pack several command and/or status bit fields of varying length into a single 8-, 16-, or 32-bit register. Most of you web services types (not meant perjoritavely) are so far away from the hardware you never have to mess with such stuff (and probably good riddance, from your perspective, no?). However, even on 32-bit embedded processors (note: over 50% of new embedded designs are with 32-bit processors), bit fields most definitely have their place.

They are also useful for packing data into communication streams. But one must remember that bit fields are explicitly non-portable, so using them to communicate between dissimilar architectures, or even similar architectures with differernt compilers, is more than a bit tricky.

...and raise you an Intel 8748: 64 BYTES of on-chip RAM (which also included the two register sets and the stack...oh, wait a minnit-that 64 BYTES was the stack... and 2KB of on-chip EEPROM. Used it to make an IEEE-488 interface controller for light-pipe data acquisition controllers for an EMP measurement system.

And no, it is definitely not before my time... ;-).

Actually, it defines the number of bits that the field (a.k.a. member) will occupy. If several fields with this :n specification will fit into a storage unit (generally, an int), then the compiler, at its discretion, and according to its own rules, can pack several of these fields into the same storage unit. Note that the ANSI standard leaves the rules of how these things are packed up to the "implementation" (that is, the compiler), so bit fields are specifically not portable. If you are going to back up things from one type of machine and restore them on another, do not even think of using bit fields as part of the back-up format.

SpiceWare is right, in that the number that follows the colon can be something other than one. The number determines how many bits to reserve in the storage unit for that field. The number cannot be greater that the size of the storage unit., so you can't say something like:

\nstruct big_ass\n{\n   unsigned int   super_long_int:128;\n};\n\n

Also, as someone else here said, you cannot take the address of a bit field; the compiler will not take kindly to such an attempt.

Finally, the field must still have a type. The ANSI standard requires the implementation to support all the integer types, but does not require the implementation to actually only reserve that sized storage unit for it. For example, the compiler is supposed to accept something like:

\nstruct its_OK\n{\n   unsigned char   a_field:4;\n   unsigned char   a_nother_field:5;\n};\n

But you cannot assume that the size of the structure is 2 bytes. (Since 9 bits have been allocated, the structure cannot fit into a single byte.) It can legally be as large as 8 bytes (on a 32-bit machine).

HTH...