{"title":"Pointers & Arrays","description":null,"content":"C-style arrays and pointers in C++ are tangled together in a way that confuses almost everyone the first time they meet it. In most expressions an array name silently turns into a pointer to its first element, which is why `arr[i]` and `*(arr + i)` mean the same thing, and why a function that \"takes an array\" is really taking a pointer. This chapter pulls that relationship apart so you can read array code, write functions that operate on arrays, and avoid the classic \"where did my array size go?\" bug.\n\n---\n\n# Array Names Decay to Pointers\n\nWhen you use the name of a C-style array in most contexts, the compiler converts it into a pointer to the first element. This conversion is called **array-to-pointer decay**, or just **array decay**. The array still exists in memory the same way it did before, but the expression `arr` evaluates to `&arr[0]`, a pointer to the first slot.\n\nHere's the decay happening in plain sight:\n\n\n```cpp\n#include \n\nint main() {\n double prices[5] = {29.99, 14.99, 9.99, 49.99, 19.99};\n\n double* p = prices; // decay: prices becomes &prices[0]\n double* q = &prices[0]; // explicit form of the same thing\n\n std::cout << \"prices points to: \" << *p << std::endl;\n std::cout << \"q points to: \" << *q << std::endl;\n std::cout << \"Same address? \" << (p == q) << std::endl;\n return 0;\n}\n```\n\n\nBoth `p` and `q` end up holding the same address, which is the address of the first element. The first assignment didn't need an explicit `&prices[0]` because the array name `prices`, used in a value context, already meant exactly that.\n\nThis is the single most important rule for this chapter: in almost every expression you write, an array name is a pointer to its first element. It's not literally a pointer (a pointer variable has its own storage; the array doesn't), but it behaves like one whenever you use it.\n\n---\n\n# `arr[i]` is `*(arr + i)`\n\nOnce you accept that an array name behaves like a pointer to its first element, indexing makes a lot more sense. The expression `arr[i]` is defined to mean `*(arr + i)`. The brackets are syntactic sugar over pointer arithmetic.\n\n\n```cpp\n#include \n\nint main() {\n int stock[5] = {10, 20, 30, 40, 50};\n\n std::cout << \"stock[2] = \" << stock[2] << std::endl;\n std::cout << \"*(stock + 2) = \" << *(stock + 2) << std::endl;\n\n int* p = stock;\n std::cout << \"p[2] = \" << p[2] << std::endl;\n std::cout << \"*(p + 2) = \" << *(p + 2) << std::endl;\n return 0;\n}\n```\n\n\nAll four expressions read the same memory. `stock + 2` advances by two `int` slots (eight bytes on most systems, but the arithmetic is in elements, not bytes), and dereferencing reads the value at that address. Once `stock` has decayed to a pointer, indexing through `stock`, indexing through `p`, and writing the dereferenced arithmetic all do the same job.\n\nThere's a strange consequence of this definition that's fun to know about. Since addition is commutative, `arr + i` and `i + arr` produce the same address, which means `*(arr + i)` and `*(i + arr)` are equivalent. The `[]` operator follows the same symmetry:\n\n\n```cpp\n#include \n\nint main() {\n int stock[5] = {10, 20, 30, 40, 50};\n\n std::cout << \"stock[2] = \" << stock[2] << std::endl;\n std::cout << \"2[stock] = \" << 2[stock] << std::endl;\n return 0;\n}\n```\n\n\n`2[stock]` is legal C++. The compiler rewrites it as `*(2 + stock)`, which is the same as `*(stock + 2)`. You will never write this in real code, and please don't, but it's a clean demonstration that `[]` is just sugar over pointer arithmetic, not a special array operator.\n\n---\n\n# Where Decay Happens, and Where It Doesn't\n\nArray decay isn't universal. It kicks in when the array name appears as a value in an expression, but a handful of contexts preserve the array type. Knowing the difference is what separates \"I can read array code\" from \"I keep getting weird sizes back\".\n\nDecay **does** happen in:\n\n- Most expressions (`arr + 1`, `*arr`, `arr == p`, passing `arr` somewhere that expects a pointer).\n- Function arguments (the next section covers this in detail).\n- Initializing a pointer (`int* p = arr;`).\n\nDecay **does not** happen in:\n\n- The operand of `sizeof` (so `sizeof(arr)` gives the byte size of the whole array, not the size of a pointer).\n- The operand of `&` (so `&arr` gives a pointer to the whole array, with a different type from a pointer to its first element).\n- When the array is bound to a reference parameter that preserves the size (`void f(int (&arr)[5])`).\n\nHere's a single program that shows all three \"no decay\" cases in action:\n\n\n```cpp\n#include \n\nvoid byPointer(int* arr) {\n std::cout << \"Inside byPointer, sizeof(arr) = \" << sizeof(arr) << std::endl;\n}\n\nvoid byReference(int (&arr)[5]) {\n std::cout << \"Inside byReference, sizeof(arr) = \" << sizeof(arr) << std::endl;\n}\n\nint main() {\n int stock[5] = {10, 20, 30, 40, 50};\n\n std::cout << \"sizeof(stock) = \" << sizeof(stock) << std::endl;\n std::cout << \"sizeof(stock[0]) = \" << sizeof(stock[0]) << std::endl;\n std::cout << \"Element count = \" << sizeof(stock) / sizeof(stock[0]) << std::endl;\n\n int* p = stock;\n std::cout << \"sizeof(p) = \" << sizeof(p) << std::endl;\n\n std::cout << \"stock address = \" << static_cast(stock) << std::endl;\n std::cout << \"&stock address = \" << static_cast(&stock) << std::endl;\n\n byPointer(stock);\n byReference(stock);\n return 0;\n}\n```\n\n\nThree things are worth pulling out of that run. First, `sizeof(stock)` is `20`, which is `5 * sizeof(int)` on a typical 64-bit system. The compiler still knows the full type of `stock` inside `sizeof`, because `sizeof` is one of the operators where decay is suppressed. Dividing by `sizeof(stock[0])` is the classic \"how many elements does this array have?\" idiom. Second, `stock` and `&stock` print the same address but have different types. `stock` decays to `int*`, while `&stock` has type `int (*)[5]`, a pointer to an array of five ints. The numeric value is the same; the type is not. Third, inside `byPointer` the array has decayed, so `sizeof(arr)` reports the size of a pointer. Inside `byReference` the parameter type `int (&arr)[5]` preserves the array, so `sizeof(arr)` reports the full byte size.\n\nThe exact pointer size from `sizeof(p)` depends on the platform: 8 bytes on a 64-bit system, 4 on a 32-bit system. The numeric output for the addresses will differ across runs and machines.\n\n\n> **INFO**\n>\n> **Cost:** `sizeof` is a compile-time operator. It produces a constant and never reads memory at runtime, so the idiom `sizeof(arr) / sizeof(arr[0])` is free. The only thing it costs you is correctness when `arr` has already decayed to a pointer.\n\n\n---\n\n# Passing Arrays to Functions\n\nFunctions are where array decay becomes a daily concern. The moment you write `void sumCart(double arr[])`, the compiler rewrites the parameter as `double* arr`. The function never receives the array as an array. It receives a pointer to the first element, and the size information is lost at the call site.\n\nAll three of these declarations are exactly the same function:\n\n\n```cpp\ndouble sumCart(double arr[], int count);\ndouble sumCart(double arr[10], int count); // the 10 is ignored\ndouble sumCart(double* arr, int count);\n```\n\n\nThe third form is the most honest about what's really happening, and it's the form most experienced C++ code uses. The first two look like they're carrying size information, but they aren't. Here's a working example:\n\n\n```cpp\n#include \n\ndouble sumCart(double* prices, int count) {\n double total = 0.0;\n for (int i = 0; i < count; i++) {\n total += prices[i]; // same as *(prices + i)\n }\n return total;\n}\n\nint main() {\n double cart[5] = {29.99, 14.99, 9.99, 49.99, 19.99};\n int count = sizeof(cart) / sizeof(cart[0]); // compute size BEFORE decay\n\n double total = sumCart(cart, count);\n std::cout << \"Cart total: $\" << total << std::endl;\n return 0;\n}\n```\n\n\nA few things to notice. The size calculation happens in `main`, where `cart` is still a real array and `sizeof(cart)` gives the full byte count. The function signature takes a `double*` and an `int count`, the standard \"pointer plus length\" idiom. Inside the function, `prices[i]` works exactly like it did on the original array, because indexing on a pointer is the same operation as indexing on an array (`*(prices + i)`).\n\nThe standard `for` loop form here is intentional. A range-based `for` loop would not work inside the function, because range-based `for` needs a real array or a container with `begin()` and `end()`. Once the array has decayed to a pointer, there's no way to know where the end is, which is exactly why we have to pass `count` separately.\n\n### The Famous Pitfall: Lost Size Information\n\nThe reason this matters is that getting the size wrong inside a function is the single most common array bug in C++. Here's the broken version:\n\n\n```cpp\n#include \n\ndouble sumCartBroken(double prices[]) {\n // BUG: inside the function, prices is a pointer.\n // sizeof(prices) is the size of a pointer, not the array.\n int count = sizeof(prices) / sizeof(prices[0]);\n double total = 0.0;\n for (int i = 0; i < count; i++) {\n total += prices[i];\n }\n return total;\n}\n\nint main() {\n double cart[5] = {29.99, 14.99, 9.99, 49.99, 19.99};\n std::cout << \"Total: $\" << sumCartBroken(cart) << std::endl;\n return 0;\n}\n```\n\n\nOn a 64-bit system, `sizeof(prices)` is 8 and `sizeof(prices[0])` is 8 (for a `double`), so `count` is `1`. The loop sums only the first element and stops. The total is wildly wrong, but the program compiles cleanly and runs without crashing, which is what makes the bug nasty. The compiler will usually issue a warning if you build with `-Wall`, but a lot of legacy code lives on without that warning enabled.\n\n\n> **INFO**\n>\n> **Cost:** The \"size inside a function\" bug doesn't cost you CPU. It costs you correctness. The function still runs at the same speed; it just produces the wrong answer.\n\n\n### Better Options Than Raw Pointers\n\nThe pointer-plus-length idiom is the foundation, and you need to know it because it appears in millions of lines of C and C++ code. But modern C++ has cleaner options for new code:\n\n\n```cpp\n#include \n#include \n\ndouble sumCart(const std::vector& prices) {\n double total = 0.0;\n for (double p : prices) {\n total += p;\n }\n return total;\n}\n\nint main() {\n std::vector cart = {29.99, 14.99, 9.99, 49.99, 19.99};\n std::cout << \"Cart total: $\" << sumCart(cart) << std::endl;\n return 0;\n}\n```\n\n\nA `std::vector` carries its own size, supports range-based `for`, and doesn't decay. Passing it by `const&` avoids a copy. For functions that need to operate on either a raw array or a vector or a `std::array`, C++20 added `std::span`, which is a non-owning view that bundles a pointer and a length together. That's beyond the scope of this chapter, but it's worth knowing the option exists.\n\nThe takeaway: prefer `std::vector` (or `std::array` for fixed sizes) for new code. Use the pointer-plus-length idiom when you're working with a raw array, an existing API, or a C interop boundary. Either way, you now know what's happening underneath.\n\n---\n\n# Memory Layout: An Array and a Pointer to It\n\nThe reason all of this works is that an array is just a contiguous block of memory, and a pointer is just an address. When `prices` decays to `&prices[0]`, the resulting pointer points to the first element. Indexing with `prices[i]` or `*(prices + i)` walks forward through the same block, one element at a time.\n\n\n```mermaid\nflowchart LR\n subgraph PTR[\"Pointer variable (own storage)\"]\n P[\"p
holds: 0x1000\"]:::ptr\n end\n\n subgraph ARR[\"Array prices on the stack\"]\n A0[\"prices[0]
29.99
0x1000\"]:::primary\n A1[\"prices[1]
14.99
0x1008\"]:::primary\n A2[\"prices[2]
9.99
0x1010\"]:::primary\n A3[\"prices[3]
49.99
0x1018\"]:::primary\n A4[\"prices[4]
19.99
0x1020\"]:::primary\n end\n\n P -- \"points at\" --> A0\n A0 -. \"p + 1\" .-> A1\n A1 -. \"p + 2\" .-> A2\n A2 -. \"p + 3\" .-> A3\n A3 -. \"p + 4\" .-> A4\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef ptr fill:#ffa94d,stroke:#000,color:#000\n```\n\n\nThe array itself, `prices`, lives in a single contiguous run of bytes. Each `double` takes 8 bytes on a typical system, so the addresses go up by 8 between neighboring elements. The pointer `p`, by contrast, has its own little slot of memory somewhere else (also on the stack here), and that slot holds the address `0x1000`. Writing `p + 1` doesn't change `p`; it produces a new address one element further on. Dereferencing that new address reads `prices[1]`.\n\nThis is also why `stock` and `&stock` print the same numeric address but have different types. They start at the same byte. `stock` decays to a pointer to one `int`, while `&stock` is a pointer to \"the whole block of five `int`s\". They differ in what `+ 1` means: pointer arithmetic on `int*` moves by 4 bytes, pointer arithmetic on `int (*)[5]` moves by 20 bytes.\n\nThe addresses in the diagram are made up for illustration. The actual addresses you'll see on your machine will differ on every run because the stack layout is decided at runtime, but the relative offsets between elements are always the size of one element.\n\n---\n\n# A Practical Pattern: Pointer Walk Over an Array\n\nOnce you internalize the decay rule, a common pattern in C++ is to walk through an array using a pointer instead of an index. It's just another spelling of the same loop, and you'll see it in libraries, in legacy code, and in interview questions.\n\n\n```cpp\n#include \n\nint countInStock(int* stock, int count) {\n int inStock = 0;\n int* end = stock + count; // one past the last element\n for (int* p = stock; p < end; p++) {\n if (*p > 0) inStock++;\n }\n return inStock;\n}\n\nint main() {\n int stock[6] = {3, 0, 7, 0, 2, 0};\n int count = sizeof(stock) / sizeof(stock[0]);\n std::cout << \"Products in stock: \" << countInStock(stock, count) << std::endl;\n return 0;\n}\n```\n\n\nThe pointer `p` starts at the first element and advances one element per iteration. The sentinel `end` is `stock + count`, which is a \"one-past-the-end\" pointer. C++ guarantees that computing this address is legal, but dereferencing it is undefined behavior. That's the same convention the standard library uses for iterators, and it's why `vec.end()` is \"past the last element\", not \"the last element\".\n\n\n> **INFO**\n>\n> **Cost:** Walking with a pointer and walking with an index compile to roughly the same machine code on modern compilers. Pick whichever reads more clearly. The pointer form is sometimes faster on older compilers and constrained platforms, but on a modern toolchain it's a style choice, not a performance one.\n\n\n---\n\n# A Quick Word on Multidimensional Arrays\n\nWhen a 2D array like `int grid[3][4]` decays, it doesn't become a `int**`. It becomes a pointer to an array of four ints: `int (*)[4]`. The first dimension is lost; the second is part of the element type and stays.\n\n\n```cpp\n#include \n\nvoid printRow(int (*row)[4]) {\n for (int i = 0; i < 4; i++) {\n std::cout << (*row)[i] << \" \";\n }\n std::cout << std::endl;\n}\n\nint main() {\n int grid[3][4] = {\n {1, 2, 3, 4},\n {5, 6, 7, 8},\n {9, 10, 11, 12}\n };\n printRow(&grid[0]);\n printRow(&grid[1]);\n return 0;\n}\n```\n\n\nThe exotic-looking `int (*)[4]` syntax is part of the cost of using raw multidimensional arrays. Most production code reaches for `std::vector>`, a flat 1D vector with manual indexing, or `std::array` when sizes are known at compile time. The point for this chapter is that decay still happens for multidimensional arrays, just one dimension at a time.\n\n---\n\n# Common Misreadings\n\nA few patterns confuse beginners more than anything else. They're all consequences of the rules above, but they're worth calling out by name so you can spot them in code reviews.\n\n`int arr[5]` and `int* p` are not the same type, even though they often appear interchangeable. You can write `p = arr;` because `arr` decays. You cannot write `arr = p;`, because `arr` is not a modifiable variable. It's the name of a fixed block of memory.\n\n`sizeof(arr)` inside a function never tells you the array size. The \"array\" parameter is a pointer, full stop. If you need the size, pass it. If you can change the API, take a `std::vector` or `std::span` by reference.\n\n`arr[i]` and `*(arr + i)` are not \"almost\" the same. They are defined to be the same. Compilers don't optimize one into the other; the language standard says they mean the same thing. That's also why negative indices like `arr[-1]` are syntactically legal: they compile to `*(arr - 1)`, which may or may not point at a valid object. Don't write them unless you really know `arr` is offset into a larger buffer.\n\nA function parameter written as `int arr[]` or `int arr[100]` is a pointer. The number, if you wrote one, is decoration. The compiler doesn't check it, doesn't enforce it, and doesn't preserve it. Some teams forbid the bracket form in parameters for exactly this reason, requiring `int*` instead, so the truth is visible at the call site.\n\n---\n\n# Summary\n\n- An array name in C++ decays to a pointer to its first element in most expression contexts; the conversion is silent and is the source of almost every \"weird array\" bug.\n- `arr[i]` is defined as `*(arr + i)`, which is why pointer arithmetic and indexing are interchangeable and why `i[arr]` is technically legal.\n- Decay is suppressed in three contexts: the operand of `sizeof`, the operand of `&`, and binding to a reference parameter typed as `T (&arr)[N]`.\n- Function parameters declared as `T arr[]` or `T arr[N]` are silently rewritten to `T* arr`; the size in brackets is decoration that the compiler ignores.\n- Inside such a function, `sizeof(arr)` gives the size of a pointer, not the array, so always pass the length separately, take the array by reference with a templated size, or use `std::vector` or `std::array`.\n- For new code, prefer `std::vector` or `std::array` over raw arrays; for non-owning views into either, C++20's `std::span` is the modern choice.\n- The numeric address of `arr` and `&arr` is the same, but their types differ, which changes what pointer arithmetic on each one means.\n\nThe next chapter picks up where this one ends. Once you're comfortable with a pointer that points at a single value, the next step is a pointer that points at another pointer, which is what unlocks dynamic arrays of arrays, command-line argument handling, and a cleaner mental model for double indirection.","pageType":"cpp"}

Pointers & Arrays

Get Premium