So I was looking through an older C++ book and I stumbled upon this problem:

Display the intern representation of a char.

And the way it was solved:

struct bits{
unsigned b0:1;
unsigned b1:1;
unsigned b2:1;
unsigned b3:1;
unsigned b4:1;
unsigned b5:1;
unsigned b6:1;
unsigned b7:1;

};

union character{
bits b;
char c;
};


character byte;

int main(){
cin >> byte.c;

cout << byte.b.b7 << byte.b.b6 << byte.b.b5 << byte.b.b4;
cout << byte.b.b3 << byte.b.b2 << byte.b.b1 << byte.b.b0;

}
}

And I got a bit confused, because there was some syntax I've never seen before:

unsigned b0:1;

What type is b0? And what does ":1" do?

The way the code works, it appears that b0 is of type BIT, which I'm not sure can happen in C++.

http://en.cppreference.com/w/cpp/language/bit_field

"unsigned" is a shorthand for unsigned int.

isn't the code in the original post technically venturing into undefined behavior land

Unions is in list of allowed types for aliasing. C++ Standard section 3.10 item 10:

10 If a program attempts to access the stored value of an object through a glvalue of other than one of the
following types the behavior is undefined: 52

....

— an aggregate or union type that includes one of the aforementioned types among its elements or non-
static data members (including, recursively, an element or non-static data member of a subaggregate
or contained union),

....

So there's no problems with undefined behavior.

You need to be a bit careful when using bitfields, as there are some significant portability issues. Some of them affect correctness, and others just affect how much space saving you get.

• For the example in the OP sizeof(character) may vary depending on which compiler you've used (I'd expect either sizeof(unsigned) or sizeof(char)). If it ends up as sizeof(unsigned), then endianness will cause portability problems if you write to one member then read from the other.
• The order of the bits within a bitfield isn't well defined either, so writing to b.b0 and then reading c isn't portable even if you avoid the size/endianness issue.
• Various other stuff also isn't defined. For example there's several different numbers this code could output: struct test {int p:4; unsigned int q:4;}; printf("%d\n", sizeof(test));

One thing you should definitely avoid for cross platform portability is serializing anything that contains a bitfield. It's even worse than writing out a whole struct. Use masks and shifts instead if you need to be space efficient.

C99 6.7.2.1-11:An implementation may allocate any addressable storage unit large enough to hold a bit- field. If enough space remains, a bit-field that immediately follows another bit-field in a structure shall be packed into adjacent bits of the same unit. If insufficient space remains, whether a bit-field that does not fit is put into the next unit or overlaps adjacent units is implementation-defined. The order of allocation of bit-fields within a unit (high-order to low-order or low-order to high-order) is implementation-defined. The alignment of the addressable storage unit is unspecified.

isn't well defined either

It is one of those borderline edge cases of the language standard.

There are several classes of behavior:

There is well-defined behavior that is specified in the standard. These things MUST be a particular way. Most of the language standard falls in this arena.

There is implementation defined behavior that is outlined by the standard but the compiler or system sets the value. These are usually properties of the underlying machine or compiler such as the number of bits in a data type, the maximum number of characters in a name, the depth of nesting that is legal, and so on.

There is unspecified behavior that is generally outlined by the standard. Usually the standard defines several options and allows the system to do whatever they want inside those bounds. For example, the order of evaluation of function arguments is unspecified. The standard requires the process must happen, but the standard allows broad latitude to how and when it happens.

There is undefined behavior that the standard has no requirements for. The most classic of these is the result of following a null pointer or following a pointer into unknown locations. The behavior is completely undefined by the standard and the system could do anything, from crashing, to warning with error messages, to doing what the programmer thinks might happen.

Individual compilers are allowed to write their own extensions and define their own behavior. They must provide the values for implementation defined behavior, such as stating that the maximum identifier length is x bytes, or the allowable depth of template recursion, and so on.

In this case the standard defines that they must exist, but allows most of the underlying details to be unique to the compiler.

Bit fields have a lot of implementation defined behavior. The underlying type, the number of bits, the packing of the bits, the allocation within a class object, the alignment, the straddling of allocation units, all of these are implementation defined.

Yes, technically you're only allowed to read from the same union member which was previously written. However, (almost) every C/C++ compiler actually recommends using unions in this exact way when you intend to perform a bitwise reinterpretation of a value.

Yes, this is one of those obscure little semi-guarantees in the standard that ALMOST every compiler takes steps to ensure.

The standard offers a guarantee, but the guarantee is based on implementation defined behavior.

You don't really see bitfields in desktop applications because there's no need to conserve memory.

Sure there is need to conserve memory. Pulling data from the main RAM is slow (relatively speaking). The more memory you can fit into cachelines without complex operations, the faster things can go.

This isn't to say you should always compress your memory down - like most computer programming, you need to learn when is the appropriate situation to do so. But I definitely wouldn't say you "don't need to" anymore than I'd say you "always need to". Both are incorrect (though can be hyperbolically used to make a point - if that's what you were doing, it went over my head ).

Like most programming, there's a balance:

"Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%." - Donald Knuth

Many programmers know the "premature optimization is the root of all evil.", but the whole quote is more nuanced.

Sometimes conserving memory in RAM can "actually have a strong negative impact" not just with debugging and maintenance, but even performance-wise as well. Othertimes, it can dramatically improve performance by 10-15% or more, permitting you to make your game more complex in other areas. A 10% reduction of your frames' average runtime is a big deal.

Note, I'm talking about conserving memory in general, not bitfields in particular. Bitfields can sometimes be pretty slow, but they are useful in other areas.