Lecture 14: Dynamic Memory and Linked Lists

## Two questions Lecture 13 left open · How many records, and for how long?

**How many?** Readings arrive while the program runs. `std::array<Reading, 3>` cannot grow, and you do not know the count when you compile. (Lecture 10's `std::vector` can grow: it keeps its elements on the free store. Today you see how.)

**For how long?** A function that builds a record cannot return the address of a local:

~~~cpp
Reading* makeReading(int id, double v) {
    Reading r{id, v, true};
    return &r;                      // dangling: r is destroyed here
}
~~~

~~~text
warning: address of stack memory associated with local variable 'r' returned
~~~

**Today's answer: the free store.** `new` creates an object that lives until `delete`, and a pointer is how you reach it. That is why pointers came first.

~~~cpp
Reading* makeReading(int id, double v) {
    return new Reading{id, v, true};  // lives until the owner calls delete
}
~~~

Plan: `new` and `delete` → who owns the object (`unique_ptr`) → a linked list that grows one node at a time.

## Example: two lifetimes · A local object and a free-store object

~~~cpp
#include <iostream>

int* makeOnHeap() {
    int* p = new int{42};        // dynamic: lives until delete
    return p;
}

int main() {
    int local = 7;               // automatic: destroyed at the closing brace
    int* heap = makeOnHeap();    // the function ended, the object did not
    std::cout << local << ' ' << *heap << '\n';
    delete heap;                 // the owner releases it
    heap = nullptr;
}
~~~

~~~text
7 42
~~~

An automatic object is destroyed when its scope ends. A free-store (dynamic) object lives until <code>delete</code>, so the code that owns it must release it exactly once. The pointer is the one from Lecture 13, now pointing at storage we control.

## unique_ptr · Exclusive ownership, released automatically

~~~cpp
#include <iostream>
#include <memory>
#include <utility>

int main() {
    auto first = std::make_unique<int>(42);
    std::cout << *first << '\n';
    std::unique_ptr<int> second = std::move(first);   // ownership moves
    std::cout << (first == nullptr) << ' ' << *second << '\n';
}   // second releases the int here
~~~

~~~text
42
1 42
~~~

- A smart pointer (<code>std::unique_ptr</code>) owns one object and runs <code>delete</code> in its destructor, so no <code>delete</code> is written.
- There is exactly one owner. Copying is not allowed; <code>std::move</code> transfers ownership and leaves the source null.
- It prevents ownership leaks, but a separate non-owning raw pointer can still dangle.

## Ownership errors · Leak, dangling pointer, double deletion

| Error | Example | Result |
|---|---|---|
| Memory leak | `p = new int{7};` while `p` still owns another `int` | the first object is unreachable and never released |
| Dangling pointer | `int* q = p; delete p; *q` | undefined behavior: `q` still holds the address of a dead object |
| Double deletion | `delete p; delete p;` | undefined behavior |
| Mismatched form | `delete` on `new[]` storage, or `delete[]` on `new` | undefined behavior |
| Allocation failure | `new int[huge]` | `new` throws `std::bad_alloc` |

Each error breaks the rule "one owner, one release". <code>unique_ptr</code> removes the leak and the double deletion; it cannot remove a dangling observer.

## A linked list · Nodes connected by next pointers

~~~cpp
#include <iostream>

struct Node {
    int value;
    Node* next;              // address of the next node, or nullptr
};

int main() {
    Node* second = new Node{20, nullptr};   // the last node: next is nullptr
    Node* head = new Node{10, second};      // head holds the first node's address
    std::cout << head->value << ' ' << head->next->value << '\n';
    std::cout << (head->next->next == nullptr) << '\n';
    delete head;
    delete second;
}
~~~

~~~text
10 20
1
~~~

A linked list stores a sequence in separate nodes. Each node holds a value and a pointer to its successor. The pointer <code>head</code> gives access to the first node, and <code>nullptr</code> marks the end. An empty list is <code>head == nullptr</code>.

## Build and summarize a list · Readings inserted at the head

~~~cpp
#include <iostream>

struct Node {
    int value;
    Node* next;
};

Node* pushFront(Node* head, int value) {
    return new Node{value, head};           // the new node points at the old head
}

int sum(const Node* head) {
    int total = 0;
    for (const Node* current = head; current != nullptr; current = current->next) {
        total += current->value;            // every node before current has been added
    }
    return total;
}

void release(Node* head) {
    while (head != nullptr) {
        Node* rest = head->next;            // save the link before the node dies
        delete head;
        head = rest;
    }
}

int main() {
    Node* head = nullptr;
    for (int reading : {31, 29, 33, 30}) {
        head = pushFront(head, reading);
    }
    for (const Node* n = head; n != nullptr; n = n->next) std::cout << n->value << ' ';
    std::cout << '\n';
    std::cout << "sum " << sum(head) << '\n';
    release(head);
    head = nullptr;
    std::cout << "empty sum " << sum(head) << '\n';
}
~~~

~~~text
30 33 29 31
sum 123
empty sum 0
~~~

**Takeaways**

- Insertion at the head takes the same few steps for any length, but it reverses the order: the last reading inserted is the first in the list.
- <code>sum</code> works for the empty list without a special case, because the loop condition fails at once when <code>head</code> is <code>nullptr</code>.
- The caller owns the list and calls <code>release</code> once. Each <code>new</code> in <code>pushFront</code> has one matching <code>delete</code>.

## Traversal and insertion · Follow next until nullptr, add at the head

~~~cpp
for (Node* current = head; current != nullptr; current = current->next) {
    std::cout << current->value << ' ';    // process one node
}

head = new Node{value, head};              // insert at the head
~~~

- Invariant: every node before <code>current</code> has been processed.
- The loop stops at <code>nullptr</code>. It reaches the end of the list without knowing the length.
- In <code>new Node{value, head}</code> the right-hand <code>head</code> is the old head. The order matters: link the new node first, then move <code>head</code>.
- Access by position is not constant time: to reach the n-th node, follow n links.

## C allocation · malloc and free manage bytes, not objects

~~~cpp
#include <cstdlib>
#include <iostream>

int main() {
    int* values = static_cast<int*>(std::malloc(3 * sizeof(int)));  // 12 untyped bytes
    if (values == nullptr) return 1;                                // malloc reports failure with nullptr
    for (int i = 0; i < 3; ++i) values[i] = (i + 1) * 10;
    std::cout << values[0] + values[1] + values[2] << '\n';
    std::free(values);                                              // free pairs with malloc, not delete
    values = nullptr;
}
~~~

~~~text
60
~~~

- <code>malloc</code> takes a size in bytes and returns <code>void*</code>, so C++ needs a cast. <code>calloc</code> also zeroes the bytes; <code>realloc</code> resizes a block.
- It does not construct or destroy C++ objects, and it never throws: it returns <code>nullptr</code> on failure.
- Pair <code>malloc</code> with <code>free</code>, and <code>new</code> with <code>delete</code>. Never mix them. Use <code>malloc</code> only where a C interface requires it.

## Let a tool find the error · AddressSanitizer on a dangling pointer

~~~cpp
int* p = new int{42};
int* q = p;              // a second pointer to the same object
delete p;                // the object dies here
std::cout << *q << '\n'; // q dangles: undefined behavior
~~~

Compiled with <code>g++ -std=c++17 -g -fsanitize=address</code>, the run stops and reports (lines shortened, addresses vary):

~~~text
ERROR: AddressSanitizer: heap-use-after-free on address 0x6020000000f0
READ of size 4 at 0x6020000000f0 thread T0
    #0 ... in main a4.cpp:7
freed by thread T0 here:
    #1 ... in main a4.cpp:6
~~~

- The report names the read of freed memory (line 7) and the line that freed it (line 6).
- Without the sanitizer, the same program ran here and printed <code>4</code>, a value that was not <code>42</code>. The result of such code is undefined: it may print the old value, a different value, or crash.
- A second <code>delete p;</code> is reported the same way as <code>attempting double-free</code>. A leak is found by a leak checker, which this platform's sanitizer does not provide, so no leak report is shown here.

## Questions about dynamic memory (1)

| Question | Answer |
|---|---|
| Why not just use a local variable? | A local object ends with its scope and its size is fixed at compile time. Use the free store when the object must outlive the function or its size is known only at run time. |
| Is "heap" the same as "free store"? | In everyday use, yes. The standard says free store for `new`/`delete` and reserves "heap" for the C-style allocator, but both name memory obtained at run time. |
| Does `delete p` set `p` to `nullptr`? | No. It releases the object and leaves `p` holding the old address. Assign `nullptr` yourself. |
| What happens if I forget `delete`? | A memory leak. The storage is returned to the system when the program ends, but a long-running program keeps growing. |
| Can I `delete` a local variable's address? | No. Only storage obtained from `new` may be passed to `delete`. This is undefined behavior. |
| What does `new int` (no braces) contain? | An uninitialized `int`. Write `new int{}` or `new int{42}` so the value is defined. |

## Questions about dynamic memory (2)

| Question | Answer |
|---|---|
| Why can't I copy a `unique_ptr`? | Two owners would both release the object. Use `std::move` to transfer ownership, or pass the object by reference to share access without ownership. |
| Does `unique_ptr` make dangling impossible? | No. It releases its own object. A raw pointer copied from it with `get()` can still outlive it. |
| Why `make_unique` and not `new`? | It states ownership in one expression and leaves no `new` without an owner. Prefer it. |
| Why a linked list and not an array? | Insertion at the head is cheap and the list grows one node at a time. But the n-th element takes n steps to reach, and each node carries an extra pointer. |
| Can a list be circular? | Yes, if the last `next` points back to the first. Then traversal to `nullptr` never ends, so such a list needs a different stopping rule. |
| Is `malloc` ever correct in C++? | Only when a C interface hands you or demands a `malloc`ed block. For your own objects use `new` or `make_unique`. |

## Lab practice: dynamic memory and linked lists

**IC151 lab practice · 5 problems**

1. **new and delete.** Read `n`, allocate `int* a = new int[n]`, fill it with the squares `1, 4, 9, ...`, print the sum, and release it. Use the correct `delete` form.
1. **unique_ptr.** Rewrite problem 1 with `std::make_unique<int[]>(n)`. Which `delete` disappeared?
1. **Build a list.** With `struct Node { int value; Node* next; };`, read integers until `-1` and insert each at the head. Print the list, then print its length.
1. **Release.** Write `void release(Node* head)` that saves `next` before each `delete`. Compile with `-fsanitize=address` and confirm the run is clean. Then deliberately read `head->next` after `delete head` and read the report.
1. **Find or nullptr.** Write `Node* find(Node* head, int value)` that returns `nullptr` when the value is absent. Add `int front(const Node* head)` guarded by `assert(head != nullptr)`.

Reaching this set marks the lecture as studied in this browser. [Open the IC151 lab setup and batch schedule](ic151.html).