Class and Struct Memory Layouts

The Rules of the Game: The Application Binary Interface (ABI)

Before we look at a single byte of memory, we must address a fundamental point that is crucial for understanding C++ "under the hood." You might assume the C++ standard dictates exactly how an object's members are laid out in memory. This is not the case.

The C++ standard specifies the behavior of code but intentionally leaves the implementation—like the physical memory layout of objects—up to the compiler. This allows for platform-specific optimizations.

So, what ensures that code compiled with Clang can link against a library compiled with GCC on the same Linux system? The Application Binary Interface (ABI). The ABI is a set of low-level conventions for a specific platform, governing details like:

• Object memory layout
• Virtual function implementation (v-tables)
• Function calling conventions (how parameters are passed)
• Name mangling

For Linux and other Unix-like systems, the dominant standard is the Itanium C++ ABI. On Windows, Microsoft's MSVC compiler uses its own ABI. For this course, since your goal is C++ on Linux, we will be focusing on the rules of the Itanium ABI.

From C struct to C++ class

With your background in C, the struct is your natural starting point. A C struct is a contiguous block of memory where members are typically laid out in the order they are declared.

Now, let's consider a simple C++ class.

As the video shows, for simple data aggregation, a class and a struct are effectively the same at the memory level. The only difference in C++ is their default member access:

• class: members are private by default.
• struct: members are public by default.

This difference is a compile-time check and has no impact on the size or memory layout of the object.

The Reality of Memory: Alignment and Padding

Now, let's look closer at the layout. While members are laid out sequentially, the object's total size isn't always the sum of its members' sizes. This is due to memory alignment.

CPUs are most efficient when they read data from memory addresses that are a multiple of the data's size (e.g., a 4-byte int from an address divisible by 4). To ensure this, the ABI mandates that the compiler may insert unused bytes, called padding, between members or at the end of the object.

This is a classic engineering trade-off: space is traded for time (performance).

Let's see this in action.

The general rules for alignment (under the Itanium ABI) are:

1. Each member's offset from the start of the object must be a multiple of its own alignment requirement.
2. The total size of the class/struct must be a multiple of the alignment requirement of its most strictly aligned member.

Where Do the Member Functions Go?

A key difference between a C struct and a C++ class is that a class bundles data with the functions that operate on that data. A common beginner's mistake is to assume these functions are stored inside each object, increasing its size. This is incorrect.

Non-virtual member functions do not add to the size of an object. They are stored once in the program's read-only text segment (or code segment), just like any regular, non-member function.

So, how does a member function know which object's data to operate on when you call my_object.do_something()? We will cover that in detail in our next lesson, but the short answer is a hidden pointer passed to the function by the compiler.

For now, let's verify that functions and access specifiers don't affect object size.

This discovery is fundamental. It means that features like encapsulation through private members are a "zero-cost abstraction"—they make code safer and more maintainable without any performance penalty at runtime.

class MyClass {
    char a;
    double b;
    int c;
};

Conclusion

In this lesson, we established the first principle of the C++ object model: for a class without virtual functions or inheritance, its memory layout is identical to a C struct. We demystified several "under the hood" aspects that are critical for systems programming.

Key Takeaways:

• Object layout is defined by the ABI, not the C++ standard, to ensure binary compatibility.
• A simple C++ class with only data members has the same memory layout as a C struct. The class vs. struct keyword only changes the default access specifier.
• Memory alignment is a crucial performance optimization where the compiler adds padding to ensure members are located at addresses that are efficient for the CPU to access.
• Non-virtual member functions are stored in the code segment and do not increase the size of an object.
• Access specifiers (public, private) are enforced at compile time and have zero effect on memory layout or runtime performance.

We've answered the question of where data members are stored, but we've raised a new one: if member functions are just free-floating functions in the code segment, how do they know which object's data to use? Answering this will be the focus of our next two lessons, starting with an analysis of how non-virtual member functions are resolved and the role of the this pointer.