Reading https://en.cppreference.com/w/cpp/language/bit_field, are the following conclusions correct?

• whether adjacent bit-fields have no padding in between is implementation-defined (this reads different in https://eel.is/c draft/class.bit#:bit-field)
• the placement of a bit-field within the class-object is implementation-defined
• the position of the bits inside a bit-field is implementation-defined (although C 20 defines signed-integer to be 2ths complement).

(for C see: Characteristics of bit-Fields in C)

CodePudding user response：

"The question has three very clear points towards one specific feature in one language. So it would be helpful to get one answer comprising all three points of the question"

Addressing points one-by-one

• The idea that adjacent bit-fields have no padding in between, cannot be guaranteed in current implementations of C .
• Yes, the placement of a bit-field within a C class-object is implementation-defined

• "...there is no guarantee in the standard that bitfields are mapped to adjacent memory regions, although most sensible implementations would do that..."
  referenced from...

In short, the conclusion is that no guarantees exist that bit-field implementation between various new specifications of C will be consistent. Portability is therefore difficult, if not impossible from one C implementation to the other, forcing that the specifications and other documentation supporting the C compiler being used must be consulted for any application using it to be sure of its implementation (rules) regarding how padding, or other attributes of bit-fields are implemented.