Modern C++ gives you powerful tools for expressing data clearly, safely, and efficiently. This chapter teaches you how to think about types, structs, and data layout the way professional engineers do — especially in systems where performance, clarity, and modularity matter.

We will explore how data is represented in memory, how struct design affects performance, and how to build clean, predictable types that integrate naturally into larger systems.

In many languages, data layout is abstracted away. In C++, it is part of the language’s identity.

Data layout affects:

• Performance (cache friendliness, SIMD, memory access patterns)
• Correctness (alignment, padding, binary formats)
• Interoperability (graphics APIs, serialization, networking)
• Architecture (how systems communicate and store state)

Even if you never write low level code, understanding data layout makes you a better C++ engineer.

Modern C++ encourages you to think in terms of three broad categories:

1. Value Types
   Small, self contained objects that behave like mathematical values.
   Examples:
   • int, float, bool
   • std::string
   • std::array<T, N>
   • Custom math types (vectors, matrices)
   Value types are cheap to copy, cheap to move, and easy to reason about.
2. Aggregate Types (Structs)
   Collections of values grouped together.
   Examples:
   • struct transform { vec3 pos; vec3 rot; vec3 scale; };
   • struct vertex { vec3 pos; vec3 normal; vec2 uv; };
   Aggregates define data layout explicitly.
3. Object Types (Classes with invariants)
   Types that enforce rules, invariants, or behavior.
   Examples:
   • File (must close handle)
   • Texture (must release GPU resource)
   • Window (must destroy OS handle)
   Object types use RAII and encapsulation.

This chapter focuses on value types and aggregate types, the foundation of clean data design.

In modern C++:

• struct → public by default
• class → private by default

That’s the only difference.

Use struct when representing plain data:

struct vec3
{
    float x, y, z;
};

Use class when representing behavior or invariants:

class Texture
{
public:
    Texture(const std::string& path);
    ~Texture();

private:
    GLuint id;
};

This simple convention makes code more readable and intentional.

A good struct:

• Has no hidden invariants
• Has no resource ownership
• Has no complex behavior
• Is cheap to copy and move
• Represents pure data

Example:

struct transform
{
    vec3 position;
    vec3 rotation;
    vec3 scale;
};

This struct is predictable, easy to serialize, and easy to use.

C++ aligns data for performance. This can introduce padding between members.

Example:

struct Example
{
    char a;   // 1 byte
    int b;    // 4 bytes
    char c;   // 1 byte
};

Memory layout might be:

a _ _ _ b b b b c _ _ _

Padding ensures proper alignment for int.

What this affects:

• Binary formats
• GPU buffers
• Networking
• Serialization
• Memory footprint
• Cache behavior

How to reduce padding: Group members by size:

struct ExampleOptimized
{
    int b;
    char a;
    char c;
};

This produces tighter layout:

b b b b a c _ _

A POD type:

• Has no constructors
• Has no virtual functions
• Has no private members
• Has no custom behavior
• Has standard layout

POD types are ideal for:

• GPU buffers
• File formats
• Network packets
• Serialization
• Interop with C APIs

Example:

struct vertex
{
    float x, y, z;
    float nx, ny, nz;
    float u, v;
};

This struct is POD and safe to memcpy.

Math types are the backbone of graphics and simulation.

Example:

struct vec3
{
    float x, y, z;

    vec3() = default;
    vec3(float x, float y, float z)
        : x(x), y(y), z(z) {}
};

These types should be:

• Small
• POD
• Inline
• Cheap to copy
• Cheap to pass by value

Avoid heap allocation inside math types.

Modern C++ uses clear rules:

void Move(vec3 delta);

void SetTransform(const transform& t);

void AttachChild(Node* child);

void Update(transform& t);

These conventions make APIs predictable.

Good type design:

• Uses meaningful names
• Avoids unnecessary getters/setters
• Keeps data public in structs
• Keeps invariants private in classes
• Avoids hidden ownership
• Avoids surprising behavior

Example of clear design:

struct Color
{
    float r, g, b, a;
};

Example of unclear design:

class Color
{
private:
    float* data; // heap allocation
public:
    Color();
    ~Color();
};

The second version is harder to reason about and unnecessary.

In this chapter, we saw:

• Why data layout matters
• The difference between value types, aggregate types, and object types
• When to use struct vs class
• How alignment and padding affect memory
• What POD types are and why they matter
• How to design clean, engine friendly math types
• How to pass types correctly (value, reference, pointer)
• How to design types for clarity and predictability

These principles form the foundation for the architectural chapters that follow.