C++.

The compiler manages stack memory for you, while heap memory is something you request and give back yourself.

The stack holds function locals and parameters. Each call pushes a frame, the block that holds that call's locals, and each return pops it. So cleanup is automatic and free. The stack is small, often one to eight megabytes. Deep recursion or a huge local array can overflow it and crash 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 memory you never release leaks.

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

A reference is another name for an existing object, while 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, and a reference usually has neither.

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& always receives a real object, so it needs no null check.

A pointer to const cannot be used to change the object it points at. A const pointer cannot be made to point anywhere else. To tell them apart, read the declaration from right to left. 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 only stops writes through that pointer. The object itself may still change through some other non-const handle. A const pointer has a fixed address for its whole 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 manage 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. It can be moved but not copied. It is as small and fast as a raw pointer, which 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 use it only when no single object can be the owner.

weak_ptr owns nothing. It observes an object held by shared_ptr and can tell whether it is still alive. You call lock() to get a usable shared_ptr, which is empty if the object is gone.

A memory leak is heap memory you allocated and never released, with no pointer left to release it. Nothing crashes right away, so leaks are easy to miss. A long-running server just grows until the allocator or the operating system kills it.

The usual causes are a new with no matching delete, and an early return or a thrown exception that skips the cleanup. Overwriting the only pointer to a block leaks it too.

The fix in modern C++ is structural, not a matter of discipline. Store owned objects in unique_ptr, shared_ptr or a standard container, and their destructors free them on every exit path. For what still slips through, build with AddressSanitizer or run a leak checker. Both name the allocation site.

Its destructor runs automatically when control leaves the enclosing block. That happens whether you reach the closing brace, return early, or throw.

The order is strictly the reverse of construction. Locals are destroyed 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

This order keeps dependent resources safe. A connection that logs during shutdown can rely on the logger still being alive.

Only objects with automatic storage get this, meaning ordinary locals, not static or heap objects. A heap object made with new is untouched by scope exit, and only the pointer to it is destroyed.

A virtual function is a member function whose call is resolved at run time by the object's dynamic type, the type it was created as. Declare it virtual in the base, override it in the derived class, then call through a base pointer or reference. The derived version runs. Without virtual, the call binds to the static type, the type of the pointer or reference, and your override is skipped.

This dynamic dispatch lets you code against an interface. A render loop can call draw() through Shape pointers without knowing the real shapes, so a new shape needs no change to the loop.

The cost is one indirection per call and, usually, no inlining. That is cheap but not free, so not every function should be virtual.

A pure virtual function is declared with = 0 and needs no 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 provides a default that derived classes may replace. A pure virtual function provides nothing to fall back on. So the compiler refuses to create an object of the class, or of any derived class that leaves the function unimplemented.

Any class with at least one pure virtual function is abstract. You use it as an interface by holding objects through a Shape pointer or reference.