Complete C and C++ Tutorial

C and C++ are usually taught as one subject and are really two languages with a shared syntax and opposite philosophies. C gives you a small, complete model of the machine and expects you to manage everything. Modern C++ gives you abstractions that manage resources for you, and asks you to understand what they cost.

Writing C++ as though it were C — raw new and delete, C arrays, manual cleanup on every error path — is the single most common way to end up with the worst of both. Nearly every memory bug in C++ written since 2011 exists in code that ignored what C++11 added.

RAII is the idea the whole language is built around

Resource Acquisition Is Initialization says: tie every resource to the lifetime of an object. Acquire in the constructor, release in the destructor, and the language's own scope rules handle cleanup — including when an exception unwinds the stack, which is the case manual cleanup almost always gets wrong.

Every modern C++ facility is an application of this. std::vector is RAII for a heap array. std::lock_guard is RAII for a mutex. std::unique_ptr is RAII for a single owned pointer. Once you see the pattern, the guidance to avoid raw new and delete stops being a style rule and becomes obvious.

// C-style: every error path must remember to clean up, and a throw skips it
void process(const char* path) {
    FILE* f = fopen(path, "r");
    if (!f) return;
    char* buf = (char*)malloc(SIZE);
    if (!buf) { fclose(f); return; }     // easy to forget
    // ... a throw here leaks both ...
    free(buf);
    fclose(f);
}

// RAII: cleanup is automatic on every exit path, including exceptions
void process(const std::filesystem::path& path) {
    std::ifstream f{path};               // closed by its destructor
    if (!f) return;
    std::vector<char> buf(SIZE);         // freed by its destructor
    // ... throw anywhere; both are released correctly ...
}

Undefined behaviour is not 'it crashes'

This is the concept that most separates people who are comfortable in C and C++ from people who are not. Undefined behaviour does not mean the program does something unpredictable at that line. It means the compiler is entitled to assume it never happens, and to optimise on that assumption — so a null check after a dereference can be deleted entirely, because the dereference already promised the pointer was valid.

That is why UB bugs are so strange: the symptom appears far from the cause, changes with optimisation level, and disappears when you add a print statement. Signed integer overflow, reading an uninitialised value, out-of-bounds access, use after free and strict-aliasing violations are all in this category, and none of them reliably crash.

Pointers, references and ownership

The question a C++ reviewer asks about every pointer is not 'can it be null' but 'who owns this'. The modern convention encodes the answer in the type, so it does not have to live in a comment:

string_view and span are the newest members and the easiest to misuse: returning one that refers to a local, or binding one to a temporary, produces a dangling view with no warning from older compilers. They are views, and a view is only as valid as the thing it views.

Build systems and the linker

A large share of the time lost in C and C++ is spent not on the language but on compiling and linking. It helps to keep the pipeline stages distinct, because each produces a distinct class of error: the preprocessor pastes text, the compiler turns one translation unit into an object file, and the linker resolves symbols across all of them.

So an undefined reference is a linker error and never a syntax problem — the declaration was visible, the definition was not linked. The usual causes are a library missing from the link line, libraries listed in the wrong order, a definition that was declared but never written, or a C library included from C++ without extern "C", so the mangled name does not match.