Sizes of Types & Class Layout

Low-level SWE interview prep — primitive sizes, struct padding, std::string SSO, and where a class object actually lives

sizeof feels like it should be a simple lookup table, but it's actually the output of three separate decisions stacking on top of each other: the data model of the platform (32-bit vs. 64-bit, LP64 vs. LLP64), the alignment rules the compiler must obey, and — for anything with a constructor or virtual function — the ABI (Itanium C++ ABI on macOS/Linux, MSVC ABI on Windows) that decides where hidden machinery like vtable pointers go. This page works bottom-up: plain types first, then padding, then strings, then full class objects.

Primitive Type Sizes — 64-bit

These are typical sizes under the LP64 data model, which macOS and Linux both use. Nothing here is guaranteed by the C/C++ standard — only minimum ranges are guaranteed — but these are what every mainstream 64-bit compiler actually produces.

Struct Padding & Alignment

Every type has an alignment requirement — the address of any instance of that type must be a multiple of its alignment. For a struct, two rules follow from this: (1) each member must start at an offset that's a multiple of its own alignment, and the compiler inserts padding bytes to make that true, and (2) the struct's overall size must be a multiple of its own alignment (the largest alignment among its members), so that it packs correctly inside an array.

struct Bad {
    char   c;   // 1 byte
    int    i;   // 4 bytes
    char   c2;  // 1 byte
    double d;   // 8 bytes
};

struct Good {
    double d;   // 8 bytes
    int    i;   // 4 bytes
    char   c;   // 1 byte
    char   c2;  // 1 byte
};

std::string — Small String Optimization (SSO)

A hand-rolled "naive" string — int len; char* str; — would be 16 bytes on a 64-bit machine (4 bytes length + 4 padding + 8-byte pointer) and would always heap-allocate, even for a 1-character string. Real std::string implementations are bigger and smarter: they carry a capacity field for amortized growth, and they avoid the heap entirely for short strings by storing the characters directly inside the object.

Class Object Layout — Where Each Piece Lives, and When

Take a polymorphic class with one int, one std::string, and a virtual function:

class ZooAnimal {
public:
    ZooAnimal(const char* n) : name(n) {}
    virtual ~ZooAnimal() {}
    virtual void rotate() {}
    int loc = 0;
    std::string name;
};

Under the Itanium C++ ABI (GCC/Clang, i.e. macOS and Linux), a class that introduces virtual functions gets its hidden vtable pointer placed at offset 0 — the very front of the object, not the end. (Older compilers, like the cfront-era ones some textbooks still diagram, put it at the end — that's a real but now largely obsolete convention.)

Which segment is each piece actually in?

Process Address Space — The Big Picture

Putting It All Together