Class types

suggest change

By “class”, we mean a type that was defined using the class or struct keyword (but not enum struct or enum class).

Even an empty class still occupies at least one byte of storage; it will therefore consist purely of padding. This ensures that if p points to an object of an empty class, then p + 1 is a distinct address and points to a distinct object. However, it is possible for an empty class to have a size of 0 when used as a base class. See empty base optimisation.

class Empty_1 {};                               // sizeof(Empty_1)       == 1
class Empty_2 {};                               // sizeof(Empty_2)       == 1
class Derived : Empty_1 {};                     // sizeof(Derived)       == 1
class DoubleDerived : Empty_1, Empty_2 {};      // sizeof(DoubleDerived) == 1
class Holder { Empty_1 e; };                    // sizeof(Holder)        == 1
class DoubleHolder { Empty_1 e1; Empty_2 e2; }; // sizeof(DoubleHolder)  == 2
class DerivedHolder : Empty_1 { Empty_1 e; };   // sizeof(DerivedHolder) == 2

The object representation of a class type contains the object representations of the base class and non-static member types. Therefore, for example, in the following class:

struct S {
    int x;
    char* y;
};

there is a consecutive sequence of sizeof(int) bytes within an S object, called a subobject, that contain the value of x, and another subobject with sizeof(char*) bytes that contains the value of y. The two cannot be interleaved.

If a class type has members and/or base classes with types t1, t2,...tN, the size must be at least sizeof(t1) + sizeof(t2) + ... + sizeof(tN) given the preceding points. However, depending on the alignment requirements of the members and base classes, the compiler may be forced to insert padding between subobjects, or at the beginning or end of the complete object.

struct AnInt      { int i; };
  // sizeof(AnInt)        == sizeof(int)
  // Assuming a typical 32- or 64-bit system, sizeof(AnInt)        == 4 (4).
struct TwoInts    { int i, j; };
  // sizeof(TwoInts)      >= 2 * sizeof(int)
  // Assuming a typical 32- or 64-bit system, sizeof(TwoInts)      == 8 (4 + 4).
struct IntAndChar { int i; char c; };
  // sizeof(IntAndChar)   >= sizeof(int) + sizeof(char)
  // Assuming a typical 32- or 64-bit system, sizeof(IntAndChar)   == 8 (4 + 1 + padding).
struct AnIntDerived : AnInt { long long l; };
  // sizeof(AnIntDerived) >= sizeof(AnInt) + sizeof(long long)
  // Assuming a typical 32- or 64-bit system, sizeof(AnIntDerived) == 16 (4 + padding + 8).

If padding is inserted in an object due to alignment requirements, the size will be greater than the sum of the sizes of the members and base classes. With n-byte alignment, size will typically be the smallest multiple of n which is larger than the size of all members & base classes. Each member memN will typically be placed at an address which is a multiple of alignof(memN), and n will typically be the largest alignof out of all members’ alignofs. Due to this, if a member with a smaller alignof is followed by a member with a larger alignof, there is a possibility that the latter member will not be aligned properly if placed immediately after the former. In this case, padding (also known as an alignment member ) will be placed between the two members, such that the latter member can have its desired alignment. Conversely, if a member with a larger alignof is followed by a member with a smaller alignof, no padding will usually be necessary. This process is also known as “packing”.

Due to classes typically sharing the alignof of their member with the largest alignof, classes will typically be aligned to the alignof of the largest built-in type they directly or indirectly contain.

// Assume sizeof(short) == 2, sizeof(int) == 4, and sizeof(long long) == 8.
// Assume 4-byte alignment is specified to the compiler.
struct Char { char c; };
  // sizeof(Char)                == 1 (sizeof(char))
struct Int  { int i; };
  // sizeof(Int)                 == 4 (sizeof(int))
struct CharInt { char c; int i; };
  // sizeof(CharInt)             == 8 (1 (char) + 3 (padding) + 4 (int))
struct ShortIntCharInt { short s; int i; char c; int j; };
  // sizeof(ShortIntCharInt)     == 16 (2 (short) + 2 (padding) + 4 (int) + 1 (char) +
  //                                    3 (padding) + 4 (int))
struct ShortIntCharCharInt { short s; int i; char c; char d; int j; };
  // sizeof(ShortIntCharCharInt) == 16 (2 (short) + 2 (padding) + 4 (int) + 1 (char) +
  //                                    1 (char) + 2 (padding) + 4 (int))
struct ShortCharShortInt { short s; char c; short t; int i; };
  // sizeof(ShortCharShortInt)   == 12 (2 (short) + 1 (char) + 1 (padding) + 2 (short) +
  //                                    2 (padding) + 4 (int))
struct IntLLInt { int i; long long l; int j; };
  // sizeof(IntLLInt)            == 16 (4 (int) + 8 (long long) + 4 (int))
  // If packing isn't explicitly specified, most compilers will pack this as
  //   8-byte alignment, such that:
  // sizeof(IntLLInt)            == 24 (4 (int) + 4 (padding) + 8 (long long) +
  //                                    4 (int) + 4 (padding))

// Assume sizeof(bool) == 1, sizeof(ShortIntCharInt) == 16, and sizeof(IntLLInt) == 24.
// Assume default alignment: alignof(ShortIntCharInt) == 4, alignof(IntLLInt) == 8.
struct ShortChar3ArrShortInt {
    short s;
    char c3[3];
    short t;
    int i;
};
  // ShortChar3ArrShortInt has 4-byte alignment: alignof(int) >= alignof(char) &&
  //                                             alignof(int) >= alignof(short)
  // sizeof(ShortChar3ArrShortInt) == 12 (2 (short) + 3 (char[3]) + 1 (padding) +
  //                                      2 (short) + 4 (int))
  // Note that t is placed at alignment of 2, not 4.  alignof(short) == 2.

struct Large_1 {
    ShortIntCharInt sici;
    bool b;
    ShortIntCharInt tjdj;
};
  // Large_1 has 4-byte alignment.
    // alignof(ShortIntCharInt) == alignof(int) == 4
    // alignof(b) == 1
    // Therefore, alignof(Large_1) == 4.
  // sizeof(Large_1) == 36 (16 (ShortIntCharInt) + 1 (bool) + 3 (padding) +
  //                        16 (ShortIntCharInt))
struct Large_2 {
    IntLLInt illi;
    float f;
    IntLLInt jmmj;
};
  // Large_2 has 8-byte alignment.
    // alignof(IntLLInt) == alignof(long long) == 8
    // alignof(float) == 4
    // Therefore, alignof(Large_2) == 8.
  // sizeof(Large_2) == 56 (24 (IntLLInt) + 4 (float) + 4 (padding) + 24 (IntLLInt))

If strict alignment is forced with alignas, padding will be used to force the type to meet the specified alignment, even when it would otherwise be smaller. For example, with the definition below, Chars<5> will have three (or possibly more) padding bytes inserted at the end so that its total size is 8. It is not possible for a class with an alignment of 4 to have a size of 5 because it would be impossible to make an array of that class, so the size must be “rounded up” to a multiple of 4 by inserting padding bytes.

// This type shall always be aligned to a multiple of 4.  Padding shall be inserted as
// needed.
// Chars<1>..Chars<4> are 4 bytes, Chars<5>..Chars<8> are 8 bytes, etc.
template<size_t SZ>
struct alignas(4) Chars { char arr[SZ]; };

static_assert(sizeof(Chars<1>) == sizeof(Chars<4>), "Alignment is strict.\n");

If two non-static members of a class have the same access specifier, then the one that comes later in declaration order is guaranteed to come later in the object representation. But if two non-static members have different access specifiers, their relative order within the object is unspecified.
It is unspecified what order the base class subobjects appear in within an object, whether they occur consecutively, and whether they appear before, after, or between member subobjects.

Found a mistake? Have a question or improvement idea? Let me know.

Layout of object types:

* Layout of object types

* Class types

* Arithmetic types

* Arrays

Table Of Contents

0 Getting started

1 Literals

2 Basic type keywords

3 Operator precedence

4 Floating point arithmetic

5 Bit operators

6 Bit manipulation

7 Bit fields

8 Arrays

9 Flow control

10 const keyword

11 Loops

12 mutable keyword

13 friend keyword

14 keywords

15 Variable declaration keywords

16 auto keyword

17 Pointers

18 Type keywords (class, enum, struct, union)

19 Classes / structs

20 std::string

21 Enumeration

22 std::atomic

23 std::vector

24 std::array

25 std::pair

26 std::map

27 std::unordered_map

28 std::set and std::multiset

29 std::any

30 std::variant

31 std::optional

32 std::integer_sequence

33 std::function

34 std::forward_list

35 std::iomanip

36 Iterators

37 Basic I/O

38 File I/O

39 Streams

40 Stream manipulators

41 Metaprogramming

42 Returning multiple values from a function

43 References

44 Polymorphism

45 Value and reference semantics

46 Function call by value vs. by reference

47 Copying vs assignment

48 Pointers to class / struct members

49 The this pointer

50 Smart pointers

51 Unions

52 Templates

53 Namespaces

54 Function overloading

55 Operator overloading

56 Lambdas

57 Threading

58 Value categories

59 Preprocessor

60 SFINAE

61 Rule of three, five and zero

62 RAII

63 Exceptions

64 Implementation-defined behavior

65 Special member functions

66 Random numbers

67 Sorting

68 Regular expressions

69 Perfect forwarding

70 Virtual member functions

71 Undefined behavior

72 Overload resolution

73 Move semantics

74 Pimpl idiom

75 Copy elision

76 Fold expressions

77 Unnamed types

78 Singleton

79 ISO C++ Standard

80 User-defined literals

81 Type erasure

82 Memory management

83 Explicit type conversions

84 RTTI

85 Standard library algorithms

86 Expression templates

87 Scopes

88 Atomic types

89 static assert

90 constexpr

91 Date and time with std::chrono

92 Trailing return type

93 Function template overloading

94 Common compile linker errors

95 Design patterns

96 Optimizations

97 Compiling and building

98 Type traits

99 One definition rule

100 Unspecified behavio

101 Argument dependent name lookup

102 Attributes

103 Internationalization

104 Profiling

105 Return type covariance

106 Non-static member functions

107 Recursion

108 Callable objects

109 Constant class member functions

110 C++ vs. C++ 11 vs C++ 17

111 Inline functions

112 Client server examples

113 Header files

114 Const correctness

115 Refactoring techniques

116 Parameter packs

117 Iteration

118 type deduction

119 C++ 11 memory model

120 Build systems

121 Concurrency with OpenMP

122 Type inference

123 Resource management

124 Storage class specifiers

125 Alignment

126 Inline variables

127 Linkage specifications

128 Curiusly recurring template pattern

129 Using declaration

130 Typedef and type aliases

131 Layout of object types

132 C incompatibilities

133 Optimization

134 Semaphore

135 Thread synchronization

136 Debugging

137 Futures and promises

138 More undefined behaviors

139 Mutexes

140 Recursive mutex

141 Unit testing

142 decltype

143 Digit separators

144 C++ Containers

145 Arithmetic meta-programming

146 Contributors