Pointers & Memory

int score = 42;
int* ptr = &score;   // ptr now holds score's address

std::cout << score;   // prints 42 (the value)
std::cout << &score;  // prints something like 0x7ffee... (the address)
std::cout << ptr;     // prints the same address — ptr IS that address

&score means "give me the address WHERE score lives," not "give me score's value." This is the exact same & from Phase 3's pass-by-reference — same symbol, closely related underlying idea.

int score = 42;
int* ptr = &score;

std::cout << *ptr;   // prints 42 — follows the pointer to get the actual value
*ptr = 100;         // changes score itself, through the pointer!
std::cout << score;  // prints 100

Dereferencing (*ptr) means "go to the address this pointer holds, and give me the actual value stored there." Once you dereference a pointer, you can read OR modify the original variable directly — exactly like Phase 3's reference parameters, just made fully explicit.

int scores[5] = {85, 92, 78, 95, 88};
int* ptr = scores;  // no & needed! scores already IS an address

std::cout << *ptr;      // prints 85 — same as scores[0]
std::cout << *(ptr + 1); // prints 92 — same as scores[1]

When you use an array's name by itself, C++ treats it as the address of its FIRST element. This is precisely why scores[i] and *(scores + i) mean the exact same thing — the square-bracket syntax is genuinely just a convenient shorthand for pointer math.

int nums[] = {10, 20, 30};
int* ptr = nums;

std::cout << *ptr;       // 10
std::cout << *(ptr + 1); // 20 — moved forward by ONE int's worth of memory
std::cout << *(ptr + 2); // 30

When you add 1 to an int*, C++ automatically moves forward by the SIZE of one int (typically 4 bytes) — not literally 1 byte. This is exactly why the pointer's TYPE matters so much: int* and double* arithmetic step forward by genuinely different amounts, matching each type's actual size.

int nums[] = {10, 20, 30};
for (int* ptr = nums; ptr < nums + 3; ptr++) {
    std::cout << *ptr << " ";
}

This achieves the exact same result as for (int i = 0; i < 3; i++) { nums[i] } — just walking through memory addresses directly instead of using an index. You'll see both styles in real code; array-indexing is usually clearer, but understanding this pointer version explains what's genuinely happening underneath.

int* ptr = new int;   // creates one new int, ptr holds its address
*ptr = 42;

int* arr = new int[10];  // creates an array of 10 ints, sized at RUNTIME

new asks the operating system for a fresh chunk of memory while your program is actually running, and hands you back a pointer to it. Critically, the SIZE for new int[size] can be a variable, decided based on user input or a calculation — something a normal array declaration can't do.

Every ordinary variable you've declared so far (int score = 5;) lives on the stack — a region of memory that automatically manages itself. When a function starts, its local variables are created on the stack; when the function ends, they're automatically destroyed, with zero effort from you.

Memory created with new (Module 5) lives on the heap — a much larger region that does NOT clean up automatically. This is precisely why delete exists: you're responsible for the heap's cleanup, in exchange for the flexibility of choosing its size at runtime and having it outlive the function that created it.

void createLeak() {
    int* ptr = new int(42);
    // function ends without calling delete ptr;
    // ptr itself (the stack variable) is destroyed...
    // ...but the heap memory it pointed to is now unreachable AND still reserved!
}

A memory leak happens when heap memory is allocated with new, but the pointer to it is lost (goes out of scope, gets overwritten) before delete is ever called. That memory stays reserved — genuinely unusable by anything else — for as long as the program keeps running, since nothing has an address to reach it anymore and tell the system to free it.

A single small leak might seem harmless. But a leak inside a function called repeatedly — in a loop, or across a long-running program — accumulates. A server or application that leaks memory continuously can eventually consume all available memory and crash, sometimes after running fine for hours or days, making the root cause frustrating to trace back.

For every new, know exactly which delete matches it, and under what conditions it runs — including EVERY possible exit path out of a function (an early return, an exception). This is genuinely hard to get right by hand consistently, which is exactly why Phase 8 introduces smart pointers — a modern C++ tool that automates this cleanup correctly, without you needing to remember every single delete by hand.

int* ptr = new int(42);
delete ptr;      // memory is freed...
std::cout << *ptr;  // ...but ptr STILL holds that old address! Undefined behavior.

A dangling pointer is a pointer that still holds an address, but the memory at that address has already been freed (or otherwise no longer belongs to your program). Using it — reading OR writing through it — is undefined behavior, connecting directly back to Phase 3 Module 2's array-bounds warning: the danger is genuinely similar, just for a different reason.

int* ptr = new int(42);
delete ptr;
ptr = nullptr;    // now ptr clearly holds "nothing," not a stale address

Setting a pointer to nullptr immediately after deleting it doesn't fix the underlying memory issue, but it makes accidental future misuse much safer and more obvious — Module 9 covers nullptr properly, including how to check for it before using a pointer.

int* ptr = nullptr;   // explicitly points to nothing

if (ptr == nullptr) {
    std::cout << "ptr doesn't point to anything valid.";
}

nullptr is a special value meaning "this pointer intentionally points to nothing." It's genuinely useful as a starting value for a pointer you haven't assigned yet, and as a signal — for example, a search function can return nullptr to mean "not found," which calling code can check for explicitly.

int* ptr = nullptr;
std::cout << *ptr;  // crashes — dereferencing a null pointer

Dereferencing a nullptr is a serious, immediate error (typically an instant crash, called a "null pointer dereference" or "segmentation fault") — one of the most common real-world C++ crashes. The habit that prevents it is simple and worth making automatic:

if (ptr != nullptr) {
    std::cout << *ptr;  // only dereference after confirming it's safe
}

Build a small program that creates a dynamic array of a runtime-decided size, fills it with user input, and — the genuinely tricky part — correctly "grows" it to a larger size by allocating new memory, copying the old data over, and freeing the original.

• growArray demonstrates Module 5's new[]/delete[], Module 3's pointer-array relationship, and Module 4's copying loop all working together.
• The old array is deleted INSIDE growArray, right after copying — avoiding Module 7's memory leak by making sure every allocation has a clear, matched deletion.
• The final delete[] arr; arr = nullptr; applies Module 7's cleanup habit and Module 8's dangling-pointer-prevention pattern together, at the very end.