Base CS from zero
Data in memory: build a memory-layout model
You can recite that arrays are contiguous and objects are named slots — but the picture only becomes yours once you build it. Make a small program that lays data out in a fake memory, computes addresses the way the runtime does, and draws the difference between a value and a reference.
Turn the unit’s mental model into a working artefact: a tiny memory simulator that places arrays and objects into addressable cells, reaches any element with base + index x element_size, and shows how an array of objects becomes a graph of cells linked by references.
Build a small memory-layout model (any language) that simulates a row of addressable cells, lays out arrays and objects into it, and computes the address of any element by the same arithmetic the unit taught — proving each lookup by hand and by code.
- A worked address table for the number array: index, offset (index x element_size), computed address, and the value read — with index 0 sitting on the base address.
- elementAt returns the right value for several indices, and the code path for a large index is provably the same fixed work as for a small index (no element loop).
- Read-by-key returns the correct field value, and the two same-fields-different-order objects produce identical reads.
- The two-hop read of users[i].field is traced step by step: the array cell address, the reference stored there, the object's address, and the field value.
- A short write-up (one or two paragraphs) explaining which cells hold values and which hold references in your final layout, and why an array of objects must use references to keep its equal-size grid.
- Add a small visualiser (text or drawing) that renders the row of cells with addresses underneath and arrows from reference cells to the objects they point at — making the graph of cells visible.
- Support nested objects (an object whose field references another object) and trace a multi-hop read like company.address.city, counting the hops.
- Add a deliberately broken layout where one element is the wrong size, and show how base + index x element_size then lands on the wrong address — demonstrating why equal-size cells are required.
- Compare two layouts of the same data — an array of numbers (values inline) versus an array of single-number objects (references out) — and count how many cells and hops each costs to read one value.
Building the model makes the unit permanent: memory is a row of addressable cells; an array is a contiguous equal-size block whose elements you reach by base + index x element_size in constant time, with index 0 on the base; an object is named slots reached by key, so field order is meaningless; and an array of objects keeps its grid by storing equal-size references and reading in two hops. Once you have drawn the values and the arrows yourself, every nested data structure reads as the same graph of cells.