{"title":"Multidimensional Arrays","description":null,"content":"A 1D array holds one row of values. Plenty of real data has two coordinates instead: stock counts for each warehouse across each product, ratings each customer gave each product, sales numbers for each week in each category. This lesson covers how to declare 2D arrays, how to read and write cells, how C++ lays them out in memory, and a brief look at 3D arrays.\n\n---\n\n# Why a Second Dimension\n\n1D arrays hold a flat list of values indexed by one number. That shape is fine when there's one value per item. It stops being fine the moment data has two coordinates.\n\nConsider an online store tracking stock. There are 3 warehouses, and each warehouse stocks 4 products. The question \"how many units of product 2 are in warehouse 1?\" needs two numbers to answer. A 1D array of length 12 could fake it with a hand-computed index (`warehouse * 4 + product`), but the layout isn't visible from the code, and the math is easy to get wrong.\n\nA 2D array makes the layout explicit. Rows are one coordinate, columns are the other:\n\n\n| | Product 0 | Product 1 | Product 2 | Product 3 |\n|---|---|---|---|---|\n| **Warehouse 0** | 25 | 17 | 8 | 4 |\n| **Warehouse 1** | 12 | 30 | 5 | 9 |\n| **Warehouse 2** | 18 | 22 | 14 | 7 |\n\n\nThe same shape covers many kinds of e-commerce data. Ratings indexed by customer and product. Weekly sales by month and category. Order counts by region and day. Whenever the answer to \"how is this looked up?\" needs two coordinates, a 2D array fits.\n\n---\n\n# Declaring a 2D Array\n\nThe syntax mirrors 1D arrays, with one extra pair of brackets:\n\n\n```cpp\nint grid[3][4];\n```\n\n\nThat declares an array with 3 rows and 4 columns of `int`. The first number is the row count, the second is the column count. Both have to be compile-time constants for plain C-style arrays. The total cell count is `3 * 4 = 12`, and each cell is one `int`.\n\n\n```cpp\n#include \n\nint main() {\n int stock[3][4];\n std::cout << \"Rows: 3, Columns: 4\" << std::endl;\n std::cout << \"Total cells: \" << 3 * 4 << std::endl;\n return 0;\n}\n```\n\n\nA bare declaration like this leaves every cell uninitialized for a local array. Reading from `stock[0][0]` before writing to it is undefined behavior, the same trap as with 1D local arrays. The fix is to initialize at the same time as the declaration, covered next.\n\nA useful naming convention: when the two dimensions mean different things, give the array a name that hints at which is which. `warehouseStock[warehouse][product]` reads better than `grid[i][j]`, and the indices end up in the right order more often.\n\n---\n\n# Initializing a 2D Array\n\nC++ offers a few ways to initialize a 2D array. Choose whichever matches what's known up front.\n\nThe most explicit form is fully nested. Each inner `{...}` is one row:\n\n\n```cpp\n#include \n\nint main() {\n int stock[3][4] = {\n {25, 17, 8, 4},\n {12, 30, 5, 9},\n {18, 22, 14, 7}\n };\n\n std::cout << \"Warehouse 0, Product 0: \" << stock[0][0] << std::endl;\n std::cout << \"Warehouse 2, Product 3: \" << stock[2][3] << std::endl;\n return 0;\n}\n```\n\n\nThree inner braces, four values each. The shape of the initializer matches the shape of the array, which makes the code self-documenting: the grid is laid out visibly.\n\nZero-initialization is concise. An empty pair of braces fills every cell with `0`:\n\n\n```cpp\n#include \n\nint main() {\n int orderCount[2][3] = {};\n std::cout << \"Cell [0][0]: \" << orderCount[0][0] << std::endl;\n std::cout << \"Cell [1][2]: \" << orderCount[1][2] << std::endl;\n return 0;\n}\n```\n\n\nPartial initialization fills the cells provided and zero-fills the rest:\n\n\n```cpp\n#include \n\nint main() {\n int stock[3][4] = {\n {25, 17},\n {12}\n };\n\n for (int row = 0; row < 3; row++) {\n for (int col = 0; col < 4; col++) {\n std::cout << stock[row][col] << \" \";\n }\n std::cout << std::endl;\n }\n return 0;\n}\n```\n\n\nRow 0 got two values, so the last two cells default to `0`. Row 1 got one value, so the last three cells default to `0`. Row 2 wasn't mentioned at all, so the entire row defaults to `0`. The rule is consistent: anything not provided is set to the type's zero value.\n\nThere's also a single-flat form that drops the inner braces. C++ fills the cells in row-major order (left to right, top to bottom):\n\n\n```cpp\n#include \n\nint main() {\n int stock[2][3] = {25, 17, 8, 12, 30, 5};\n\n for (int row = 0; row < 2; row++) {\n for (int col = 0; col < 3; col++) {\n std::cout << stock[row][col] << \" \";\n }\n std::cout << std::endl;\n }\n return 0;\n}\n```\n\n\nThe first three values fill row 0, the next three fill row 1. The compiler accepts this, but most code prefers the nested form because the row structure is visible. The flat form is fine for small arrays and gets unreadable fast.\n\nA side-by-side of the four initialization styles:\n\n\n| Style | Syntax | Effect |\n|-------|--------|--------|\n| Fully nested | `{{1,2},{3,4}}` | Each inner brace is one row, values map 1:1 |\n| Zero-init | `{}` | Every cell set to `0` |\n| Partial nested | `{{1,2},{3}}` | Listed cells set, the rest zero-filled |\n| Single flat | `{1,2,3,4}` | Filled row-major, no inner braces |\n\n\n---\n\n# Indexing and Iterating\n\nIndexing a 2D array uses two bracket pairs, in `[row][col]` order. The first index picks the row, the second picks the cell inside that row.\n\n\n```cpp\n#include \n\nint main() {\n double weeklySales[3][4] = {\n {1200.50, 950.00, 1430.75, 880.25},\n {1100.00, 1020.50, 1380.00, 990.00},\n {1350.75, 1180.25, 1500.50, 1050.00}\n };\n\n std::cout << \"Week 0, Category 0: $\" << weeklySales[0][0] << std::endl;\n std::cout << \"Week 2, Category 3: $\" << weeklySales[2][3] << std::endl;\n\n weeklySales[1][2] = 1400.00;\n std::cout << \"Updated Week 1, Category 2: $\" << weeklySales[1][2] << std::endl;\n return 0;\n}\n```\n\n\nReading and writing both use the same `[row][col]` form. Indices start at `0`. The first row is row `0`, the first column is column `0`. The last row of a 3-row array is row `2`, not row `3`.\n\nUnlike some languages, C++ does not check that indices are in range. Writing to `weeklySales[5][0]` when there are only 3 rows is undefined behavior. The program might appear to work, might print garbage, might crash, or might corrupt unrelated memory. The compiler won't catch it. There's no exception. The result is a broken program that may fail in ways that look unrelated.\n\nBounds checks are absent in raw arrays for a reason: every access stays a single load with no comparison. The tradeoff is that one bad index can overwrite a neighboring variable. For bounds-checking, `std::array::at()` and `std::vector::at()` throw on out-of-range access. Both are covered in later lessons.\n\nTo visit every cell, nest two `for` loops. The outer one walks the rows, the inner one walks the columns of the current row:\n\n\n```cpp\n#include \n\nint main() {\n int stock[3][4] = {\n {25, 17, 8, 4},\n {12, 30, 5, 9},\n {18, 22, 14, 7}\n };\n\n for (int warehouse = 0; warehouse < 3; warehouse++) {\n for (int product = 0; product < 4; product++) {\n std::cout << stock[warehouse][product] << \" \";\n }\n std::cout << std::endl;\n }\n return 0;\n}\n```\n\n\nEach iteration of the outer loop produces one row of output. Inside it, the inner loop walks all four columns and prints them on the same line. After the inner loop ends, `std::endl` finishes the line so the next row starts fresh.\n\nThe same pattern handles aggregations. The total stock across all warehouses and products:\n\n\n```cpp\n#include \n\nint main() {\n int stock[3][4] = {\n {25, 17, 8, 4},\n {12, 30, 5, 9},\n {18, 22, 14, 7}\n };\n\n int total = 0;\n for (int warehouse = 0; warehouse < 3; warehouse++) {\n for (int product = 0; product < 4; product++) {\n total += stock[warehouse][product];\n }\n }\n\n std::cout << \"Total stock: \" << total << std::endl;\n return 0;\n}\n```\n\n\nThe accumulator `total` lives outside both loops so it survives every iteration. Declaring `total` inside the outer loop would compute a per-warehouse total instead, a different (and easy to write by accident) calculation.\n\nHardcoding the sizes (`3` and `4`) works, but it's fragile. Changing the array shape later requires updating every loop. A safer approach uses `sizeof` to compute the dimensions:\n\n\n```cpp\n#include \n\nint main() {\n int stock[3][4] = {\n {25, 17, 8, 4},\n {12, 30, 5, 9},\n {18, 22, 14, 7}\n };\n\n int rows = sizeof(stock) / sizeof(stock[0]);\n int cols = sizeof(stock[0]) / sizeof(stock[0][0]);\n\n std::cout << \"Rows: \" << rows << \", Columns: \" << cols << std::endl;\n return 0;\n}\n```\n\n\n`sizeof(stock)` is the byte size of the entire 2D array. `sizeof(stock[0])` is the byte size of one row. Dividing gives the row count. The same trick on a single row gives the column count. This only works while `stock` is still a real array. The section on passing 2D arrays to functions explains why that matters.\n\n---\n\n# Row-Major Memory Layout\n\nA C++ 2D array sits in memory as a single contiguous block. There are no separate row allocations, no pointers, no indirection. The cells of row 0 come first, then the cells of row 1 right after them, then row 2, and so on. This is **row-major** layout, the rule for any built-in array type in C++.\n\nFor `int stock[3][4]` on a typical system where `int` is 4 bytes, the 12 cells take 48 contiguous bytes:\n\n\n```mermaid\nflowchart LR\n R0C0[\"stock[0][0]
byte 0\"]:::cyan\n R0C1[\"stock[0][1]
byte 4\"]:::cyan\n R0C2[\"stock[0][2]
byte 8\"]:::cyan\n R0C3[\"stock[0][3]
byte 12\"]:::cyan\n\n R1C0[\"stock[1][0]
byte 16\"]:::orange\n R1C1[\"stock[1][1]
byte 20\"]:::orange\n R1C2[\"stock[1][2]
byte 24\"]:::orange\n R1C3[\"stock[1][3]
byte 28\"]:::orange\n\n R2C0[\"stock[2][0]
byte 32\"]:::teal\n R2C1[\"stock[2][1]
byte 36\"]:::teal\n R2C2[\"stock[2][2]
byte 40\"]:::teal\n R2C3[\"stock[2][3]
byte 44\"]:::teal\n\n R0C0 --> R0C1 --> R0C2 --> R0C3 --> R1C0 --> R1C1 --> R1C2 --> R1C3 --> R2C0 --> R2C1 --> R2C2 --> R2C3\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n```\n\n\nRow 0's four cells take bytes 0 through 15. Row 1's start at byte 16, right after row 0 ends. Row 2 picks up at byte 32. The cells inside a row are adjacent. The cells across rows are also adjacent at the row boundary. There are no gaps and no extra metadata.\n\nPrinting addresses confirms this is one block:\n\n\n```cpp\n#include \n\nint main() {\n int stock[3][4] = {\n {25, 17, 8, 4},\n {12, 30, 5, 9},\n {18, 22, 14, 7}\n };\n\n std::cout << \"&stock[0][0]: \" << &stock[0][0] << std::endl;\n std::cout << \"&stock[0][3]: \" << &stock[0][3] << std::endl;\n std::cout << \"&stock[1][0]: \" << &stock[1][0] << std::endl;\n std::cout << \"&stock[2][3]: \" << &stock[2][3] << std::endl;\n std::cout << \"Difference between row 0 and row 1 starts (in ints): \"\n << (&stock[1][0] - &stock[0][0]) << std::endl;\n return 0;\n}\n```\n\n\n**Output:** (exact addresses vary; the differences are the point)\n\n\n```shell\n&stock[0][0]: 0x7ffeeae0a8d0\n&stock[0][3]: 0x7ffeeae0a8dc\n&stock[1][0]: 0x7ffeeae0a8e0\n&stock[2][3]: 0x7ffeeae0a8fc\nDifference between row 0 and row 1 starts (in ints): 4\n```\n\n\nThe address of `stock[1][0]` is exactly one `int` past `stock[0][3]`. The address arithmetic between row starts is 4 (the column count). Every cell sits exactly where a row-major block would place it.\n\nThis matters in two practical ways. First, the convention \"first index = row\" matches how memory is laid out. Stick with it. Second, the CPU's cache loads memory in chunks (typically 64 bytes at a time). Walking the array row by row brings several upcoming cells into cache with each load, so the next few accesses are cheap. Walking column by column skips past most of each cache load and needs a fresh fetch for every cell.\n\nIterating in row-major order (outer loop = rows) is several times faster than column-major order on large arrays, because of cache locality. For a 1000x1000 array of ints, the difference can be 5 to 10x in real time. For small arrays it doesn't matter. For big ones, prefer row-major access unless there's a reason not to.\n\nThe contrast with some other languages is real but not relevant here. Java's 2D arrays, for example, are arrays of references to separate row arrays, so rows can live anywhere on the heap. C++ built-in 2D arrays are a single contiguous block. There's no indirection.\n\n---\n\n# Beyond 2D: 3D Arrays\n\nIf two dimensions cover most cases, three dimensions show up occasionally. The syntax adds another set of brackets.\n\nA natural e-commerce use is stock counts indexed by warehouse, product, and month:\n\n\n```cpp\n#include \n\nint main() {\n // [warehouse][product][month]\n int stock[2][3][4] = {};\n\n stock[0][1][2] = 150;\n stock[1][2][0] = 80;\n\n std::cout << \"Warehouse 0, Product 1, Month 2: \" << stock[0][1][2] << std::endl;\n std::cout << \"Warehouse 1, Product 2, Month 0: \" << stock[1][2][0] << std::endl;\n std::cout << \"Total cells: \" << 2 * 3 * 4 << std::endl;\n return 0;\n}\n```\n\n\nThe pattern extends without surprise. `stock[2][3][4]` is two layers of three rows of four columns. The memory is still one contiguous block, laid out in the same row-major scheme, with three coordinates instead of two. Walking every cell needs three nested loops.\n\nMost code never goes past 2D. When a third dimension comes up, ask whether the data really has three independent coordinates, or whether a class with named fields would read better. A `WarehouseInventory` object with named members is often easier to maintain than `stock[w][p][m]`, where each index's meaning has to be remembered or commented.\n\n---\n\n# Passing a 2D Array to a Function\n\nPassing a 2D array to a function is one of the parts of C++ that surprises beginners. It works, but there's a constraint to understand first.\n\nA function that prints a 2D array:\n\n\n```cpp\n#include \n\nvoid printStock(int stock[][4], int rows) {\n for (int r = 0; r < rows; r++) {\n for (int c = 0; c < 4; c++) {\n std::cout << stock[r][c] << \" \";\n }\n std::cout << std::endl;\n }\n}\n\nint main() {\n int warehouseStock[3][4] = {\n {25, 17, 8, 4},\n {12, 30, 5, 9},\n {18, 22, 14, 7}\n };\n printStock(warehouseStock, 3);\n return 0;\n}\n```\n\n\nThe parameter type is `int stock[][4]`. The first dimension is empty, the second is `4`. The row count gets passed separately as `rows`. The same parameter can be written as `int (*stock)[4]`, which means the same thing in C++ (a pointer to an array of 4 ints), but `int stock[][4]` reads more naturally for beginners.\n\nThe column count cannot be left off:\n\n\n```cpp\nvoid broken(int stock[][], int rows, int cols) {\n // error: declaration of 'stock' as multidimensional array\n // must have bounds for all dimensions except the first\n}\n```\n\n\n`g++` rejects this with `declaration of 'stock' as multidimensional array must have bounds for all dimensions except the first`. The column count must appear in the parameter type, even when it's also passed as a separate argument. The row count can be omitted (because the function takes an unknown number of rows), but the column count is part of the type and the compiler needs it.\n\nWhy? Because the compiler needs to know the column count to compute the address of `stock[r][c]`. The formula is `base + r * column_count + c`, and without `column_count` baked into the type, the formula doesn't work. The rule: inner dimensions must be in the parameter type.\n\nA more flexible alternative is `std::vector>` or `std::array, 3>`. Those carry their dimensions with them and don't need any special parameter syntax. For raw C-style 2D arrays, the fixed-inner-dimension rule is something every C++ programmer ends up knowing.\n\n---\n\n# Common Pitfalls\n\nA handful of mistakes show up repeatedly with 2D arrays. They're all easy to fix.\n\n**Confusing `[row][col]` with `[col][row]`.** The two bracket positions look the same syntactically. Whether the first index means rows or columns is a convention, but it has to be consistent everywhere. Mixed conventions in the same codebase are a guaranteed bug. Pick \"first index = row\" (which matches row-major memory layout) and use it in declarations, loops, and function signatures.\n\n**Forgetting that partial initialization zero-fills.** Writing `int stock[3][4] = {{25, 17}};` only fills two cells of one row. The other ten cells are zero, not garbage, not the value of the cell next to them. This is sometimes the intended behavior and sometimes a surprise. Skipping the initializer entirely leaves cells uninitialized, but that's almost never a good idea.\n\n**Using the wrong size in nested loops.** A common bug is reusing the outer loop bound for the inner loop:\n\n\n```cpp\nfor (int r = 0; r < 3; r++) {\n for (int c = 0; c < 3; c++) { // wrong if the array is 3x4\n // ...\n }\n}\n```\n\n\nFor a square array this works by accident. For a rectangular array it either misses cells or runs past the end into undefined behavior. The fix is to use the right bound for each loop, computed with `sizeof` or stored as named constants:\n\n\n```cpp\nconst int ROWS = 3;\nconst int COLS = 4;\nint stock[ROWS][COLS] = { /* ... */ };\nfor (int r = 0; r < ROWS; r++) {\n for (int c = 0; c < COLS; c++) {\n // ...\n }\n}\n```\n\n\n**Out-of-range indices.** C++ doesn't check that indices are in range. `stock[3][0]` on a 3-row array reads memory past the end of the array. The program might keep running and print a plausible-looking value, but that value belongs to some other variable. Always match loop bounds to the array dimensions, and prefer `std::vector::at()` or `std::array::at()` (covered in the std::array lesson and the STL section) when a runtime check is needed.\n\n**Passing the array around without the inner dimension.** As shown above, function parameters need the column count in the type. Skipping it is a compile error. The reason connects to how arrays decay to pointers, covered in the Pointers & Arrays lesson, but the practical takeaway: keep the inner dimension in the parameter type.\n\nA picture of how the nested loop walks the grid:\n\n\n```mermaid\nflowchart TD\n Start[Start nested loops]:::cyan --> OuterInit[row = 0]:::orange\n OuterInit --> OuterCheck{row less than
row count?}:::orange\n OuterCheck -- false --> Done[Done]:::green\n OuterCheck -- true --> InnerInit[col = 0]:::teal\n InnerInit --> InnerCheck{col less than
col count?}:::teal\n InnerCheck -- true --> Body[visit stock row col]:::cyan\n Body --> InnerUpdate[col plus plus]:::teal\n InnerUpdate --> InnerCheck\n InnerCheck -- false --> OuterUpdate[row plus plus]:::orange\n OuterUpdate --> OuterCheck\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n```\n\n\nThe inner loop runs to completion for every iteration of the outer loop. Total work is `rows * cols` cell visits. For a 100x100 array that's 10,000 cells, which is nothing. For a 10000x10000 array that's 100 million, which is when cache locality starts to matter.","pageType":"cpp"}

Multidimensional Arrays

Get Premium