const

You already finished Introductory. I will not re-teach the absolute first hello. We build upward.

const is a promise: this name will not be used to mutate the object through this binding. const int n = 3; initializes n to 3 and forbids n = 4 afterward — a compile error, not a runtime shrug. That early refusal is the point. You document intent for readers and you give the compiler a rule to enforce. When the compiler or runtime complains, read the first error first — later errors are often fallout. Change one thing. Rebuild. That calm loop beats rewriting the whole file from memory. const is a promise you make to the compiler and to your future self. Prefer it by default on values and references you don't intend to mutate — the type system will catch slip-ups. Before you build, predict what const should do on the still's inputs. Prediction turns compiling into confirmation.

Prefer const by default when a value should not change. Mutability should be the exception you can justify. Local constants, configuration values, and loop bounds you don't intend to tweak are all const candidates. The habit scales: const member functions, const references, const correctness in APIs. When the compiler or runtime complains, read the first error first — later errors are often fallout. Change one thing. Rebuild. That calm loop beats rewriting the whole file from memory. Zero-based indexing is the tax you pay once and forever. When something looks one-off, count from zero on paper before you blame the standard library. Before you build, predict what const should do on the still's inputs. Prediction turns compiling into confirmation.

const int& is a read-only alias. You avoid copying a large object while still forbidding mutation through that name. Functions that only inspect data should take const T& for non-trivial T. Callers read the signature and know their object won't be changed. Ownership is the plot of modern C++. Ask who creates the object, who may use it, and who destroys it. If you can't answer, you're guessing — and guessing with pointers is how undefined behavior sneaks in. const is a promise you make to the compiler and to your future self. Prefer it by default on values and references you don't intend to mutate — the type system will catch slip-ups. Before you build, predict what const should do on the still's inputs. Prediction turns compiling into confirmation.

Top-level const on a pointer (int* const) means the pointer itself can't aim elsewhere; const int* means you can't mutate the int through the pointer. Read right-to-left when parsing. Today the still is the simple case: const int n — immutable int binding. Ownership is the plot of modern C++. Ask who creates the object, who may use it, and who destroys it. If you can't answer, you're guessing — and guessing with pointers is how undefined behavior sneaks in. const is a promise you make to the compiler and to your future self. Prefer it by default on values and references you don't intend to mutate — the type system will catch slip-ups. Before you build, predict what const should do on the still's inputs. Prediction turns compiling into confirmation.

const interacts with APIs: you can't pass a const object to a function that takes T& non-const without a cast (don't cast away const casually). Design functions to accept const when they don't mutate. That makes more call sites legal and safer. Ownership is the plot of modern C++. Ask who creates the object, who may use it, and who destroys it. If you can't answer, you're guessing — and guessing with pointers is how undefined behavior sneaks in. const is a promise you make to the compiler and to your future self. Prefer it by default on values and references you don't intend to mutate — the type system will catch slip-ups. Before you build, predict what const should do on the still's inputs. Prediction turns compiling into confirmation.

constexpr (Expert territory for depth) is a stronger compile-time cousin. For Easy, master const as everyday hygiene. If you reach for a comment that says “don't change this,” reach for const instead — the compiler reads const; it doesn't read your comment. const is a promise you make to the compiler and to your future self. Prefer it by default on values and references you don't intend to mutate — the type system will catch slip-ups. Saving a file is not building it. Compile, read the first diagnostic, fix, repeat. The build line is part of the language experience — treat it as seriously as the source. Before you build, predict what const should do on the still's inputs. Prediction turns compiling into confirmation.

const int n = 3;

const int n = 3; creates an int that must stay 3 through that name. Any later assignment to n is a compile error. There's no main in the still on purpose — the declaration itself is the idea. Drop const and assignment would be legal; keep const and the type system guards you.

Pitfalls: thinking const makes the object live in ROM always (it doesn't for ordinary locals); confusing const int* with int* const; casting away const to “just fix it”; forgetting const on reference parameters that shouldn't mutate. Prefer const until mutation is required.

You've promised not to change a value — and the compiler will help you keep it. Next: nullptr.