C++ Memory Segmentation Overview

C++ applications organize runtime memory into distinct zones, each governing data lifespan, access permissions, and allocation mechanisms. This architectural division enables developers to optimize resource utilization and control object lifetimes precisely. The standard memory layout comprises four primary sections:

• Code Section: Contains compiled machine instructions. Operating systems share this segment across processes executing identical binaries to conserve RAM. It is typically marked read-only to prevent accidental instruction modification during execution.
• Global/Data Section: Hosts static data persisted throughout program execution. This includes externally declared variables, statically scoped entities, immutable constants, and literal strings. The runtime environment automatically reclaims this memory upon process termination.
• Stack: Managed implicitly by the compiler. Stores function call frames, including parameters, return addresses, and automatic/local variables. Memory here follows LIFO discipline, with allocation and deallocation occurring automatically upon scope entry and exit.
• Heap: Dedicated to dynamic memory requests initiated at runtime. Developers manually request and relinquish blocks using allocation operators. Leaks occur if explicit deallocation fails, though host process termination forces OS-level cleanup.

Verifying Segment Locations

Examining variable addresses reveals which zone owns specific data types. The following routine demonstrates address mapping across scopes:

#include <iostream>

// External storage
int ext_val_a = 42;
int ext_val_b = 99;
constexpr const int c_ext = 55;

void inspect_memory() {
    // Automatic storage
    int auto_a = 10;
    int auto_b = 20;

    // Static storage
    static int stat_x = 7;
    static int stat_y = 14;
    constexpr const int c_auto = 8;

    std::cout << "Automatic variables:\n"
              << "  auto_a @ " << reinterpret_cast<void*>(&auto_a) << "\n"
              << "  auto_b @ " << reinterpret_cast<void*>(&auto_b) << "\n";
    std::cout << "Static variables:\n"
              << "  stat_x @ " << reinterpret_cast<void*>(&stat_x) << "\n"
              << "  stat_y @ " << reinterpret_cast<void*>(&stat_y) << "\n";
    std::cout << "Constants & Literals:\n"
              << "  string_lit @ " << static_cast<const char*>("benchmark") << "\n"
              << "  c_ext      @ " << reinterpret_cast<const void*>(&c_ext) << "\n"
              << "  c_auto     @ " << reinterpret_cast<const void*>(&c_auto) << "\n";
}

int main() {
    inspect_memory();
    return 0;
}

When executed, output clusters reveal two distinct address ranges. Variables declared inside functions reside in one contiguous block (stack), while externals, statics, literals, and constants group together elsewhere (global/data area). Immutable local variables typically align with the global data zone due to compile-time evaluation rules.

Stack Execution Dynamics

Since stack frames vanish after function boundaries, retaining references to internal variables creates dangling pointers. Consider the following pattern:

#include <iostream>

int* create_ref() {
    int temp = 200; 
    return &temp; // Returns address of a dying local variable
}

int main() {
    int* invalid_ptr = create_ref();
    std::cout << "Dereferencing released stack frame: " << *invalid_ptr << '\n';
    return 0;
}

Although some compilers cache recently freed registers temporarily (yielding predictable initial values), relying on this behavior violates strict memory safety standards. Once the calling function completes, that memory slot becomes immediately eligible for reuse.

Heap Alllocation Mechanics

Dynamic memory bypasses automatic scope rules, granting persistent access until explicitly freed. The new operator facilitates this:

#include <iostream>

int* allocate_single() {
    int* raw_ptr = new int(300);
    return raw_ptr;
}

void manage_heap_object() {
    int* owned = allocate_single();
    std::cout << "Current value: " << *owned << '\n';
    
    delete owned; // Explicit deallocation required
    std::cout << "Accessing freed memory triggers undefined behavior.\n";
}

int main() {
    manage_heap_object();
    return 0;
}

Unlike stack variibles, heap blocks survive function exits. Neglecting delete causes memory fragmentation over extended execution periods.

Dynamic Arrays on the Heap

Extending allocation to collections requires bracket notation during deallocation to ensure complete resource recovery:

#include <iostream>

void initialize_dynamic_array() {
    size_t capacity = 8;
    int* sequence = new int[capacity];

    for (size_t idx = 0; idx < capacity; ++idx) {
        sequence[idx] = idx * 10;
    }

    for (size_t idx = 0; idx < capacity; ++idx) {
        std::cout << "Element " << idx << ": " << sequence[idx] << '\n';
    }

    delete[] sequence; // Must match new[] syntax
}

int main() {
    initialize_dynamic_array();
    return 0;
}

Omitting the square brackets in delete results in unedfined behavior or partial destructor invocation for custom types. While primitive types may tolerate syntactic mismatches on certain platforms, maintaining operator parity prevents subtle runtime corruption.