Stack memory is managed for you by the compiler; heap memory you ask for and give back yourself.

The stack holds function locals and parameters. Each call pushes a frame, each return pops it, so cleanup is automatic and free. It is small, often one to eight megabytes, and blowing past it with deep recursion or a huge local array crashes the process.

The heap is a separate pool you allocate from at runtime. Objects there live until something frees them, so they can outlive the function that created them. Allocation costs a real call into the allocator, and forgetting to release leaks.

Default to the stack. Reach for the heap when the object must outlive the current scope. Also use it when the size is known only at runtime, or the object is too big for a frame.

A reference is another name for an existing object; a pointer is an object that stores an address.

That difference drives everything else. A reference must be initialized when declared and can never be reseated to a different object. A pointer can be null, can be reassigned, and can be moved through an array with arithmetic. A pointer also has its own storage and its own address; a reference usually has neither.

Practically: use a reference when the thing must exist and will not change identity. Use a pointer when absence is meaningful, when you need to rebind, or when you walk memory.

References make the contract clearer at the call site. A function taking const std::string& promises it will not be handed nothing, so it needs no null check.

Read the declaration from right to left and the two fall out cleanly. const binds to whatever sits on its left, unless nothing is there, in which case it binds right.

int x = 1, y = 2;
const int* p = &x;   // *p is read-only; p = &y is fine
int* const q = &x;   // *q = 5 is fine; q = &y will not compile

A pointer to const means you may not write through that pointer. The object itself may still change through some other non-const handle. A const pointer means the address is fixed for the pointer's life, so it must be initialized at declaration.

Pointer to const is the one you write constantly. It is how a function says it will read your data and not modify it. That lets callers pass constants safely, and lets the compiler catch an accidental write.

Smart pointers are class templates that own a heap object and free it automatically when they go out of scope. You get lifetime handling without ever writing delete.

unique_ptr models sole ownership. Exactly one owns the object, it cannot be copied, only moved, and it is as small and fast as a raw pointer. That makes it the default choice.

shared_ptr models shared ownership through a reference count. The object dies when the last owner does. It costs an extra control block and atomic count updates, so reach for it only when ownership has no single home.

weak_ptr owns nothing. It observes an object held by shared_ptr and tells you whether that object is still alive. You call lock() to get a usable shared_ptr, or nothing if it is gone.

A memory leak is heap memory you allocated and never released, with no pointer left to release it. Nothing crashes right away, which is what makes leaks nasty. A long-running server just grows until the allocator or the OS kills it.

The classic shapes are a new with no matching delete, and an early return that skips the cleanup. A thrown exception does the same thing. So does overwriting a pointer that held the only handle to a block.

The fix in modern C++ is structural, not a matter of discipline. Store owned objects in unique_ptr, shared_ptr or a standard container. Their destructors run cleanup on every exit path, including the ones you forgot about.

For what still slips through, build with the address sanitizer or run a leak checker. Both name the allocation site, which is far more useful than the symptom.

Its destructor runs at the closing brace of the enclosing block, automatically. That happens whether you fall off the end, hit a return, or throw.

Order is strictly the reverse of construction. Locals die newest first, which matters when a later object depends on an earlier one. Inside one object, the destructor body runs, then members in reverse declaration order, then base classes.

{
  Logger a;
  Connection b(a);
}  // ~b runs, then ~a

That reverse ordering is what keeps dependent resources safe. A connection that logs during shutdown can count on the logger still being alive. One caveat: only automatic-storage objects get this. A heap object made with new is untouched by scope exit; just the pointer dies.

A virtual function is one the runtime picks based on the object's actual type. The type of the pointer or reference you call through does not decide it.

Declare it virtual in the base, override it in the derived class, then call through a base handle. The derived version runs. Without virtual, the call binds to the static type and your override is silently skipped.

This is what lets you write code against an interface. A render loop can hold a vector of Shape pointers and call draw() on each. It never learns whether they are circles or polygons, and adding a new shape leaves it untouched.

The cost is one indirection per call and, usually, no inlining. That is cheap but not free, so you do not mark everything virtual by reflex.

A pure virtual function is declared with = 0 and has no required implementation in the base. It says every concrete derived class must supply one.

struct Shape {
  virtual double area() const = 0;  // no body, derived classes must provide one
};  // Shape s; fails to compile, Shape is abstract

The difference from a plain virtual function is obligation. A virtual function ships a default that derived classes may replace. A pure virtual ships nothing to fall back on. So the compiler refuses to instantiate the class, and refuses any derived class that leaves it unimplemented.

Any class with at least one pure virtual is abstract. You use it as an interface: hold objects through a Shape pointer or reference. The compiler then proves that no half-finished type ever gets created.