Composite Data

Similar — both are fixed-size, homogeneous, contiguous collections:

• A C-style array (e.g. the lecture’s double[3]) and a numpy array both store n elements of one type in contiguous memory, so a[i] is O(1) and sizeof/.nbytes is just n × element size (as the earlier sizeof((int[6]){1,2,3}) cell showed). Neither can hold mixed types like Python’s list/tuple.

Different — mostly in when the homogeneity is enforced and what the size means:

1. Compile-time vs run-time coercion. In C, the element type is part of the type itself, so (double[]){1, 'a'} is a compile error. numpy enforces homogeneity at construction, silently: the cell above (np.array([(1, '2'), [False, 3]])) doesn’t error — it coerces everything to a common dtype, here a 2×2 array of 21-char strings, array([['1','2'],['False','3']], dtype='<U21'). Homogeneous result, but your numbers and booleans became strings.

2. Size is type vs data. For a C array, the length is baked into the type (int[6] is a different type from int[5]) and fixed at declaration — which is why the lecture’s ex:dot2 couldn’t loop over n. A numpy array’s shape is runtime metadata (.shape, e.g. (2, 3)), can be multidimensional, and is created/allocated at run time.

3. Primitive vs object. A C-style array is a language primitive (it decays to a pointer, has no methods); a numpy array is a full object with .dtype, .shape, and vectorized operations — conceptually closer to the C++11 std::array / std::vector containers the lecture introduces next.

All three initializers are const char[4] arrays, and the fate of each s hinges on two rules: how auto deduces an array and the storage duration of the object the pointer/reference points at.

1. auto s = (const char[4]){'a','b','c'}; — decays, and to something short-lived

Two things happen at once:

• Deduction decays. For a const char[4] lvalue, auto does not deduce the array type — it applies the standard array-to-pointer conversion, so s is deduced as const char*, not const char[4]. (sizeof s == 8, not 4; std::is_same_v<decltype(s), const char*> holds — verified with g++ and clang++.) So s is never an array; it’s a pointer to the array object.

• The object dies at the end of the full-expression. A compound literal in an expression context designates an unnamed object with automatic storage duration: its lifetime ends when the full-expression (the ;-terminated declaration) finishes. That’s why clang++ actually diagnoses it:

  warning: temporary whose address is used as value of local variable 's' will be destroyed at the end of the full-expression [-Wdangling]

  After the statement, s points at an array whose lifetime has ended — a dangling pointer. Reading through it (e.g. printing it) is undefined behavior; it looks fine because nothing has overwritten the memory yet.

2. auto &s = (const char[4]){'a','b','c'}; — binds to the array itself

With auto &, reference binding prevents the decay: s is deduced as const char(&)[4] (a reference to a const char[4], matching the type comment in your cell). No pointer is formed, so the value that matters is the array itself, and printing works because the string data is contiguous. The important caveat — which your own kernel input already shows — is that this object is still automatic storage duration, so s is equally dangling after the full-expression. It “retains the value” only in the same fragile sense as case 1: it works in practice because nothing has clobbered the stack slot, not because the standard blesses it. (g++ compiled it with no -Wdangling here because the decay form is what it pattern-matches on, not because the lifetime is valid.)

3. auto s = "abc"; — decays, but to something that lives forever

"abc" is a string literal of type const char[4] (sizeof("Ava") cell), but unlike a compound literal it has static storage duration. The same decay happens — s is again const char* — yet the pointer targets a literal object that lives for the entire program, so s stays valid.

Summary: the deduction is identical in (1) and (3) (const char*) and different in (2) (const char(&)[4]); the real discriminator is the storage duration of the object — static for "abc", automatic for both compound literals. So (3) is the only one of the three that is genuinely valid to keep around; (2) only appears to work, and (1) is UB waiting to happen (clang++ warns about it).

The short answer: v[3] in a parameter declaration doesn’t pass an array by value at all — it decays to a pointer, and the [3] bound is silently dropped. A reference parameter is the only form that keeps the array’s full type, so it’s the only one that can enforce the size.

Why print_vector3_(const auto v[3]) “fails”

Arrays aren’t copyable objects in C++, so there’s no such thing as passing an array by value. When a parameter is declared T[3], the array-to-pointer conversion applies: the function’s actual parameter is const T*. Here auto deduces const int* — verified with static_assert(std::is_same_v<decltype(v), const int*>), and sizeof v inside the function is 8 (a pointer), not 12 (three ints). g++ even diagnoses it: -Wsizeof-array-argument: "‘sizeof’ on array function parameter ‘v’ will return size of 'const int’"*. The [3] in the declaration is pure documentation.

Consequence: the compiler only requires a pointer to int, so it happily accepts (int[]){1,2} — a 2-element array. The call compiles, and the out-of-bounds read of v[2] is undefined behavior, exactly the “😈” cell above; under ASan it’s confirmed as a real bug:

ERROR: AddressSanitizer: stack-buffer-overflow
    #0 void print_vector3_<int>(int const*) ...
SUMMARY: stack-buffer-overflow in void print_vector3_<int>(int const*)

Note the mangled signature — print_vector3_<int>(int const*) — the template instantiated to a pointer parameter.

Why print_vector3(const auto (&v)[3]) works

A reference-to-array parameter doesn’t decay. auto deduces const int(&)[3] (verified: static_assert(std::is_same_v<decltype(v), const int(&)[3]>), and sizeof v inside is 12). So the argument must actually be an int[3] — a 2-element array is a different type, and the commented-out call in the cell is rejected at compile time with:

error: no matching function for call to 'print_vector3(int [2])'
note: template argument '1' does not match '2'

In one line: the by-value form carries only the element type (a const int* has forgotten how many ints there are), while the by-reference form carries the complete array type int[3] — bound included — so the size check moves from “silently UB” to “compile error.” This is the same reason the lecture’s cross(const double (&u)[3], ...) and dot(const double (&v)[], ...) take reference-to-array parameters: to get the type system to enforce (or, with [], deliberately suspend) the length.

How memory is statically allocated to an array

“Static” here means the storage is decided at compile time, not at run time — no heap call, no length negotiation. The compiler knows n × sizeof(element) up front (which is why the bounds in this lecture must be compile-time constants, e.g. the constexpr requirement in the (int[d]){1,2,3} cell), and it reserves a fixed, contiguous block:

• Global / static storage duration → the block is part of the program’s data segment, laid out when the OS loads the executable. An initialized global like int v[3]{1,2,3} goes into .data, with its initial values embedded literally in the binary (I verified: the bytes 01 00 00 00 02 00 00 00 03 00 00 00 appear in .data). An uninitialized global like int w[5] goes into .bss, which is a NOBITS section — the executable stores zero bytes for it; the loader just reserves that region in memory and the kernel zero-fills it on load.

• Automatic (stack) storage duration → the compiler reserves the block in the function’s stack frame with a single prologue adjustment, and the array lives at a fixed offset from the frame pointer. My -O0 compile of int local[4]{7,8,9,10} shows it exactly: the frame is carved out, local[2] is addressed as movl -24(%rbp), %eax (base rbp-32 plus 2 × 4 bytes). No runtime allocation — just a fixed region of the frame.

Accessing an element is the same story: v[i] compiles to base address + i × sizeof(T), all static arithmetic (v[1] → movl 4+v(%rip), %edx in my test).

Is the size stored in the executable?

No — at least not as a length attached to the data. There is no hidden “count” field in front of the array’s bytes. The size lives in two places that are not the array itself:

1. The variable’s type. v is of type int[3]; the bound is part of the type, which is why sizeof(v) works at compile time in the program (the sizeof(u) == 12 in the cell above) even though the stored bytes don’t say “3” anywhere.

2. For globals, the ELF section header carries a Size field (my readelf shows .bss of size 0x28), which tells the loader how much memory to reserve/zero — but that’s the size of the whole section, not a per-array length stored next to the array.

Because the array’s bytes carry no length with them, the extent only exists in the type. The moment the array decays to a bare pointer (int*) — e.g. when passed by value — the size is gone with the type, and the compiler can no longer check it. That’s precisely why print_vector3_(const auto v[3]) couldn’t enforce the size (the parameter is really const int*, and sizeof v there is 8, not 12), and why the reference form const auto (&v)[3] works: a reference-to-array keeps the full int[3] type — and therefore its size — intact.

Because an array isn’t a value that can be replaced — it’s a fixed region of memory whose identity is nailed down at declaration, and the language deliberately refuses to pretend = does more than that.

What v = u; would have to mean, and why each reading fails

1. “Make v refer to u’s memory” — impossible. As established in the previous answer, static allocation fixes the array’s address and extent at compile/load time: &v is a compile-time constant, and other entities can be bound to it (the lecture’s own cell 77 declares (&w)[3]=u — w is an alias for u for life). Re-pointing v would silently break everything aliased to it. Arrays are the one type you can never convert into — decay only ever goes array → pointer, never the reverse — so the left-hand side of an assignment can never “become” an array.

2. “Copy u’s elements into v” — also refused, because = would then be a lie. For every other type, copy-assignment replaces a value in O(1); for arrays it would hide an O(n) element copy. And the array’s bytes carry no length with them (the size exists only in the type, per the previous answer), so the operation is defined only through the type — the language would rather make you say it explicitly.

So g++ rejects the cell’s example outright — I verified with its exact types:

error: invalid array assignment
    5 |     v = u;

That’s not a missing operator to be worked around; array assignment is explicitly ill-formed by the standard.

The pattern it fits: the rule is “you can change what’s in a statically allocated array, but not what it is.” Initialization at birth works (double u[3]{1,2,3};), binding at birth works (auto (&w)[3] = u; — that’s reference initialization, not assignment), and mutating the contents works element-by-element (v[i] = u[i];, or via pointer/reference). When you genuinely need copy-assignment semantics, C++ gives you objects that have them: std::array (a struct wrapping an array — assignable because it’s a class type with a defined copy-assignment) and std::vector (the next topic in this lecture).

Because the outermost bound is the only dimension that isn’t needed to define the type of the array’s elements — and that’s exactly the dimension the compiler can recover or discard. It works in both places the question touches: declarations (int v[][2][3]{...}) and decay (int v[2][3] as a parameter → int (*)[2][3]).

In a declaration: the outer bound is inferable, the inner ones aren’t

int v[][2][3] declares an array of int[2][3]. The inner bounds [2][3] define the element type (a 24-byte block); the outer bound is just a count of blocks. With an initializer, the compiler counts the ints (12) and divides by the element size (6 ints per int[2][3]) → outer bound 2, inferred. (My probe: sizeof v == 48, i.e. 2 × 24.)

Skip an inner bound instead and you’re stuck: you can’t count “how many blocks” unless you know how big one block is. The element type itself would be ill-defined (int[][] has no meaning) — the last bound must be known first, which is circular. The 1D case is the same rule: int v[]{1,2,3} works because the element type int is fully known and the bound is just a count.

In decay: the conversion happens once, at the outer level, and the inner bounds are load-bearing

Array-to-pointer decay strips exactly one layer: int[2][2][3] → int (*)[2][3] — a pointer to int[2][3] (verified: my function’s mangled signature is _Z1fPA2_A3_Ki = f(int (*)[2][3]), and sizeof *p == 24). It stops there because the result is a pointer, and pointers don’t decay — only arrays do.

The inner bounds must survive the decay because subscript arithmetic is built from them. p[i][j][k] addresses as base + i·24 + j·12 + k·4 — the 24 and 12 strides are 2×3×sizeof(int) and 3×sizeof(int), both from the inner dimensions. My -O0 disassembly of p[1][0][2] shows precisely this:

movq  -8(%rbp), %rax    # p
addq  $24, %rax         # i=1 → +1×24
movl  8(%rax), %eax     # j=0, k=2 → +8 (= 0×12 + 2×4)

The outer bound — the “2” in int v[2][2][3] — appears nowhere in the addressing. p[i] is plain pointer arithmetic on a pointer whose element size (24) it already knows; how many elements exist is irrelevant to computing any one of them.

One-line version: the inner bounds define what the elements are (their size, the strides), so they can’t be skipped; the outer bound is only how many elements there are, which the initializer can count — and which pointer arithmetic never consults. That’s why int v[][2][3] compiles while int v[2][] doesn’t, and why the decayed parameter int (*p)[2][3] keeps everything after the first bracket.

They are two conventions for laying out the same multi-dimensional array in a single block of contiguous memory, and they differ in which index changes fastest in memory.

C-ordering (row-major): the last index is contiguous. In the lecture’s int v[2][2][3], the three elements v[i][j][0..2] sit next to each other, then v[i][j+1]'s three, then the next i. This is exactly the formula the cell above derives: v[i][j][k] = *(**v + i*(d[1]*d[2]) + j*d[2] + k) — k multiplies 1 (fastest), j multiplies 3, i multiplies 6 (slowest). It’s also why skipping the first bound is legal in decay: the outermost dimension’s stride is the last thing the address arithmetic needs.

F-ordering (column-major, from Fortran): the first index is contiguous, i.e. v[0..1][j][k] sit next to each other. The offset formula is the mirror image: i*1 + j*d[0] + k*d[0]*d[1] — the later (“column”) index increments slower, as the lecture’s footnote says.

Same logical array, same bytes, different address formulas. Verified with numpy on the lecture’s 2×2×3 values (1..12):

C-order flat list : [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12]
F-order flat list : [1, 7, 4, 10, 2, 8, 5, 11, 3, 9, 6, 12]

(Both agree v[1][0][2] is the 9 — the value is the same; only where each value lives differs: offset 8 in C, 9 in F.)

Is one better? No — it’s a tie by design. Performance depends only on which axis your inner loop traverses, not on the convention itself:

• In C-order, a loop for k { ... v[i][j][k] } (innermost index) reads memory sequentially — cache-friendly; the same loop in F-order would stride 6 ints at a time.

• In F-order, the innermost loop over the first index is the cache-friendly one.

Since you can always write the innermost loop over the last (or first) index respectively, either convention achieves optimal locality for a given algorithm — you just pick whichever matches the language’s convention. The real cost of the “wrong” one is only when you can’t change the loop structure (e.g. calling an existing BLAS routine that assumes its own layout), where one layout may need a transpose/copy. That’s why the ecosystem is split exactly along language lines — C/C++ row-major, Fortran column-major — and each side considers its convention the sensible one.

What stack memory is

The stack is the per-thread region where automatic-storage-duration objects live — function parameters and local variables (like the lecture’s double w[1]{123} in foo). “Automatic” means the storage is created by advancing a single pointer (the stack pointer) when the function is called and reclaimed by moving it back when the function returns. There’s no allocation call, no bookkeeping, no dynamic sizing — which is why it’s fast and safe, and why every local’s address is a fixed offset from the frame pointer (the movl $123, -8(%rbp)-style code we saw when discussing static allocation of arrays).

The crucial property: the region is valid only while the function’s frame exists. On return, the compiler just rewinds the stack pointer — the memory isn’t even explicitly freed, it’s simply reused for whatever is called next.

Why returning the address warns

The kernel’s exact warning (reproduced with the same clang here):

warning: address of stack memory associated with local variable 'w' returned [-Wreturn-stack-address]
    return w;

The chain is: return w; decays the array w[1] to a double* pointing at the local w (which is why foo’s return type came out as double*, not double[1]) — but w lives in foo’s frame, which is destroyed by the return itself. So the function hands back a pointer whose referent stops existing on the very statement that hands it out: a dangling pointer. Reading or writing through it afterward is undefined behavior, and the compiler can prove that from the language rules alone, so it warns.

The notebook’s caution cell is this in action: the global w and the local w print the same address (@0x7ffee437e298) but different values — 123 inside foo, then 1.06088e-259 / 0.0 afterward. Nothing was ever “changed” — the stack slot was simply recycled by the next function call (the cout chain) that overwrote it. My g++ run makes the same point more dramatically: the g++ 15 build warns identically (-Wreturn-local-addr) and then segfaults on reading the dangling pointer, because the g++ side had already overwritten that stack region.

The fix follows the storage-duration rules already covered in this lecture: give the data outliving storage — return a value (return w[0]; for a scalar), copy into the caller’s array (the lecture’s cross(u, v, w) pattern), or allocate with static / new (heap) when the object genuinely must outlive the function.

What an iterator is here. For std::array (and for C-style arrays, via std::begin/std::end), an iterator is a pointer into the data — v.begin() is the address of the first element, v.end() the address one-past-the-last. So “traverse with iterators” means: start at begin(), and while it != v.end(), use *it and advance with ++it.

The idiom (exactly the pattern in the lecture’s print_vector template above):

for (auto it = v.begin(); it != v.end(); ++it)
    cout << *it;

Two details worth noting from the lecture’s own code: the empty case is handled for free — if begin() == end() the loop body simply never runs — and that’s why print_vector prints the first element separately before the loop: dereferencing *it when v is empty would read out of bounds, so it guards N>0 first.

Why it’s “efficient” rather than just idiomatic.

1. Iterator arithmetic is pointer arithmetic. For contiguous ranges ++it is a single add of sizeof(T) and *it a plain load — no index × stride multiplication, and no bounds-check (the standard’s operator[] on std::array likewise checks nothing). An index loop and an iterator loop do the same memory work; the iterator form just makes the “one-past-the-end” stop condition part of the loop instead of a separate counter.

2. It’s the interface everything else uses. Range-for, std::for_each, std::accumulate, etc. all lower to this same begin/end protocol, so the same loop works unchanged for std::array, std::vector, or a raw array — which is what the lecture’s template print_vector<T, N> exploits.

3. Zero cost at -O2. I verified the claim, not just the idiom: two identical summing functions, one written with begin()/end() iterators, one with for (i = 0; i < N; ++i) — at -O2 the compiler inlines and unrolls both to the same 4-instruction body (4 addsds, no loop at all). Iterator traversal over an array is indistinguishable from the index version in machine code, so you get the algorithmic flexibility of iterators without paying any traversal overhead.

The one place to be careful: iterators are not safer than indices — *it past end() is UB, same as v[i] out of range (the lecture’s buffer-overflow exercise is the index version of the same trap). The efficiency claim is “identical to the best index loop,” not “faster than it.”

What an allocator is. An allocator is a type that owns the “where does memory come from” decision: it has allocate(n) / deallocate(p, n) (plus traits like value_type and rebind), and containers receive it as a second template parameter — std::vector<T, Allocator>, with std::allocator<T> as the default. The default allocator is essentially a thin, stateless wrapper around the global operator new / operator delete, so new/delete is not the only strategy — it’s just the built-in one.

Benefits over raw new/delete — the lecture’s two heap cells are exactly where the pain appears (new double[1] you must remember to delete[]; the for loop with new int[5] that leaks unless you pair every new with a delete[]):

1. No leaks by construction. The container owns its memory and releases it via the allocator in its destructor (RAII). delete[] w; becomes unnecessary and therefore can’t be forgotten, doubled, or applied to the wrong pointer.

2. Bulk, not per-element, allocation. new gives you one allocation at a time; an allocator can hand a container a whole chunk. Measured on 10,000 elements: std::list (each node individually allocated) performs 10,000 operator new calls, while std::vector with its default allocator performs 1 (with reserve) — better locality, far less bookkeeping.

3. Pluggable memory strategies — no code changes to the container. Swap the allocator and the same vector/list code runs on completely different memory: a static arena I used in the test performs the same 10,000-element fill with 0 calls to the global heap (1 arena allocate, 40,000 bytes from a fixed buffer). That’s how embedded/real-time code avoids the heap at runtime, and how game engines use pool allocators for speed and deterministic lifetimes.

4. Shared resources across containers (C++17 std::pmr). A polymorphic_allocator lets many containers draw from one memory_resource/pool — verified working: a pmr::vector<int> filled from an unsynchronized_pool_resource alongside everything above. With raw new there is no way to say “these 50 containers should share one slab.”

In short: new/delete hard-couple usage of memory to one strategy (the global heap) and put all release discipline on the programmer; the allocator interface pushes the strategy into a type, letting the standard containers — std::array (static, no allocator), std::vector, std::list — get safe, efficient, replaceable memory management “for free.”