{"title":"STL Overview","description":null,"content":"The Standard Template Library, or STL, is the part of the C++ standard library that gives you generic containers (like `std::vector` and `std::map`), iterators that walk those containers, algorithms that act on the iterators (like `std::sort` and `std::find`), and small function objects that customise the algorithms. It's the toolkit you reach for whenever you need to store a collection of things or run an operation across one. This chapter is the high-level map: what the STL is, how its four pieces fit together, where the headers live, and the design idea that makes it all interoperate. The remaining lessons in this section drill into each container, iterator category, and algorithm family in detail.\n\n---\n\n# What the STL Is and Why It Exists\n\nBefore the STL, every C++ project rolled its own linked list, its own hash map, its own sort routine. They were all slightly different, all incompatible, and most were buggy. Alexander Stepanov had been thinking about generic programming since the early 1980s. The idea was simple: write algorithms once, in a way that doesn't care about the specific container they operate on. Then the same `sort` works on an array, a linked list, or anything else, as long as the container provides a way to step through its elements.\n\nStepanov and Meng Lee built a prototype at HP Labs in 1993-1994. SGI later took over maintenance and the implementation that shipped with their compilers became the reference. The ISO C++ committee adopted the design and the first C++ standard (C++98) included it as part of the standard library. Today every conforming compiler ships an STL implementation: libstdc++ with GCC, libc++ with Clang, and Microsoft's STL with MSVC.\n\nThe \"Template\" in STL is the mechanism that makes it work. Templates let you write code that's parameterised by type. A `std::vector` isn't a vector of `int` or a vector of `std::string`; it's a template that generates a fresh vector class for whatever type you ask for. The same code body, instantiated for each type, with zero runtime cost compared to a hand-written equivalent.\n\nA short example shows the payoff. The same loop pattern works regardless of element type, because the container and the range-based for loop are generic.\n\n\n```cpp\n#include \n#include \n#include \n\nint main() {\n std::vector wishlist = {\"Wireless Headphones\", \"USB Cable\", \"Mouse Pad\"};\n std::vector prices = {79.99, 9.99, 14.99};\n\n for (const auto& item : wishlist) {\n std::cout << item << std::endl;\n }\n double total = 0.0;\n for (double p : prices) {\n total += p;\n }\n std::cout << \"Wishlist total: $\" << total << std::endl;\n return 0;\n}\n```\n\n\nTwo vectors with different element types, one loop pattern. The STL pulls this off by combining templates (for genericity) with iterators (for uniform traversal). The rest of this chapter unpacks both pieces.\n\n---\n\n# The Four Pillars\n\nThe STL has four moving parts. Each one exists to do a specific job, and the four are glued together by a single shared idea (iterators) that we'll cover in the next section.\n\n\n```mermaid\nflowchart LR\n A[Containers]:::cyan -->|expose| B[Iterators]:::orange\n B -->|drive| C[Algorithms]:::green\n C -->|customised by| D[Function Objects]:::teal\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n```\n\n\nThe diagram reads left to right. A container holds data. It hands out iterators that point into its storage. An algorithm takes iterators (not the container) and walks them. A function object plugs into the algorithm to customise comparisons, transformations, or predicates.\n\n### Containers\n\nContainers store collections of elements. `std::vector` is a growable array; `std::list` is a doubly-linked list; `std::map` is a sorted associative table; `std::unordered_map` is a hash table; `std::stack` and `std::queue` adapt other containers into restricted-access shapes. Each container picks a different trade-off between memory layout, access speed, and insertion cost. The chapters that follow take each one in turn.\n\nWhat containers share is the API style: a constructor, `size()`, `empty()`, a way to insert (`push_back`, `insert`), a way to remove (`erase`, `pop_back`), and methods that return iterators to the beginning and end of the collection. That shared shape is what makes the rest of the STL work.\n\n### Iterators\n\nAn iterator is an object that points to an element in a container and knows how to move to the next one. You can think of it as a generalised pointer. Like a raw pointer, you dereference it with `*` to read or write the element, and you advance it with `++`. Unlike a raw pointer, it works for any container that exposes the right operations, even ones that aren't laid out contiguously in memory.\n\nThe standard pair of iterators a container exposes is `begin()` (pointing to the first element) and `end()` (pointing one past the last element). A loop from `begin()` to `end()` visits every element exactly once. Iterators are the bridge: they let an algorithm written years before your container was written still work on your container, as long as your container's iterators behave correctly.\n\n### Algorithms\n\nAlgorithms are free functions in the `` and `` headers that operate on a range of iterators. `std::sort(begin, end)` sorts a range; `std::find(begin, end, value)` searches for a value; `std::accumulate(begin, end, init)` adds elements up. There are over 100 such algorithms in the standard library.\n\nThe crucial property is that algorithms don't know what container they're working on. `std::sort` only cares that the iterators it was handed support random access (jumping ahead by N elements in constant time). `std::find` only cares that the iterators support `++` and `*`. Algorithms are written against iterator categories, not container types, which is why the same `std::find` works on a `vector`, a `deque`, a C-style array, and even some custom container you write yourself.\n\n### Function Objects\n\nA function object (also called a **functor**) is any object that can be called like a function, meaning it overloads `operator()`. The STL uses them everywhere the behaviour of an algorithm needs to be customised. Want to sort in descending order? Pass `std::greater{}` as the comparator. Want to find the first product over $50? Pass a lambda that returns `price > 50.0`.\n\nLambdas, function pointers, classes with `operator()`, and `std::function` instances are all function objects. Chapters 22-24 of this section cover them in depth. For now, the role to remember is \"the customisation hook for algorithms.\"\n\nThe four pillars together give you a small, composable vocabulary. You pick a container for storage, get iterators from it, run algorithms over the iterators, and customise the algorithms with function objects. A single line like `std::sort(prices.begin(), prices.end(), std::greater{});` touches all four.\n\n---\n\n# Genericity Through Templates\n\nThe reason one `std::vector` template works for every element type, and one `std::sort` works for every container, is C++ templates. A template is a recipe that the compiler instantiates into concrete code when you use it with a particular type.\n\nWhen you write `std::vector prices;`, the compiler generates a class definition for `std::vector` from the `std::vector` template, substituting `double` for the type parameter. When you also use `std::vector`, the compiler generates a separate class definition for `std::vector`. The two classes share no code at runtime; each one is its own concrete type with its own methods.\n\nThis is fundamentally different from how some other languages handle generics. There's no boxing, no runtime type tag, no indirection. A `std::vector` stores raw `int`s in contiguous memory; a `std::vector` stores raw `std::string` objects (which themselves manage their own heap buffer). The compiler can inline calls, optimise tight loops, and produce code that's as fast as if you'd hand-written a custom vector class for that exact element type.\n\n\n```cpp\n#include \n#include \n\ntemplate \nvoid printFirst(const std::vector& items) {\n if (!items.empty()) {\n std::cout << items.front() << std::endl;\n }\n}\n\nint main() {\n std::vector stock = {12, 7, 3, 0, 9};\n std::vector prices = {19.99, 14.50, 9.99};\n\n printFirst(stock);\n printFirst(prices);\n return 0;\n}\n```\n\n\n`printFirst` is one function template. The compiler instantiates it twice: once for `std::vector` and once for `std::vector`. Each instantiation is a full, separate function in the resulting binary. The genericity is purely a compile-time tool.\n\n\n> **INFO**\n>\n> **Cost:** Heavy template use slows down compilation, because each instantiation is a fresh translation unit's worth of work for the compiler. It does not slow down the resulting program. Runtime cost is the same as if you'd written each version by hand.\n\n\nThe trade-off is real. A program that uses `std::vector`, `std::vector`, and `std::vector` ends up with three full copies of the vector code in the binary. For most programs that's a small cost compared to the productivity gain.\n\n---\n\n# The Iterator-as-Glue Insight\n\nThe deepest design decision in the STL is that **algorithms don't talk to containers; they talk to iterators**. This sounds like a small thing, but it changes the algebra of the library.\n\nConsider a naive design where every algorithm had to know about every container. You'd need a `sort_vector`, a `sort_list`, a `sort_deque`, and a new function every time someone added a container. Adding a new algorithm would require knowing about every existing container. The number of functions grows as containers times algorithms, which is the wrong scaling.\n\nThe STL flips this. Each container is responsible for one thing: exposing iterators that walk its elements correctly. Each algorithm is responsible for one thing: doing its work in terms of iterators. The total number of pieces grows as containers plus algorithms, which is the right scaling.\n\n\n```mermaid\nflowchart TD\n subgraph Containers[\"Containers\"]\n V[vector]:::cyan\n L[list]:::cyan\n D[deque]:::cyan\n M[map]:::cyan\n end\n\n subgraph Iterators[\"Iterators (the glue)\"]\n I[begin / end]:::orange\n end\n\n subgraph Algorithms[\"Algorithms\"]\n S[sort]:::green\n F[find]:::green\n C[count]:::green\n T[transform]:::green\n end\n\n V --> I\n L --> I\n D --> I\n M --> I\n\n I --> S\n I --> F\n I --> C\n I --> T\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n```\n\n\nThe diagram shows the layering. Containers on the left expose iterators in the middle. Algorithms on the right consume iterators. The only contract between the two sides is \"iterators behave in a documented way.\" Add a new container, expose conforming iterators, and every existing algorithm works on it. Add a new algorithm, write it against the iterator contract, and every existing container can use it.\n\nA short demo makes this concrete. The same `std::find` call works on a `vector` and a `list`, with no per-container variation.\n\n\n```cpp\n#include \n#include \n#include \n#include \n#include \n\nint main() {\n std::vector cart = {\"USB Cable\", \"Mouse Pad\", \"Wireless Headphones\"};\n std::list wishlist = {\"Keyboard\", \"Mouse Pad\", \"Webcam\"};\n\n auto inCart = std::find(cart.begin(), cart.end(), \"Mouse Pad\");\n auto inWish = std::find(wishlist.begin(), wishlist.end(), \"Mouse Pad\");\n\n std::cout << \"In cart: \" << (inCart != cart.end()) << std::endl;\n std::cout << \"In wishlist: \" << (inWish != wishlist.end()) << std::endl;\n return 0;\n}\n```\n\n\n`std::find` is the same function in both calls. The vector hands it random-access iterators that jump in O(1); the list hands it bidirectional iterators that move one step at a time. The function works in both cases because the operations it uses (`++`, `*`, `!=`) are part of the contract every iterator category honours.\n\nNot every algorithm works with every iterator. `std::sort` needs random-access iterators (to swap arbitrary elements efficiently), so calling `std::sort(list.begin(), list.end())` doesn't compile; lists provide a member `sort()` instead. The iterator category determines which algorithms are available, and the next chapter on iterator categories spells out the hierarchy.\n\n---\n\n# Container Categories\n\nThe standard containers fall into four families. The family tells you the data layout, the access pattern, and the kind of iterator you get. Future chapters cover each container in detail; the table below is the map.\n\n\n| Family | Containers | Layout / Idea | Typical Use |\n|--------|------------|---------------|-------------|\n| Sequence | `vector`, `deque`, `list`, `forward_list`, `array` | Elements stored in a particular order, accessed by position. | Lists of cart items, an order history, raw measurements. |\n| Associative (sorted) | `set`, `multiset`, `map`, `multimap` | Elements kept sorted by key, usually a balanced binary tree. | Looking things up by key with sorted traversal, ranges of keys. |\n| Unordered associative (hashed) | `unordered_set`, `unordered_multiset`, `unordered_map`, `unordered_multimap` | Hash table keyed by element or key. | Fast O(1) average lookup when order doesn't matter. |\n| Container adapter | `stack`, `queue`, `priority_queue` | Wraps an underlying container with a restricted API. | Last-in-first-out, first-in-first-out, top-priority access. |\n\n\nThe sequence containers care about order. The associative containers care about lookup by key. The adapters care about access discipline (only the top, only the front, only the back).\n\nA small example shows what each family looks like in practice. Don't worry about every method; this is just to get the shape into your head before the dedicated chapters.\n\n\n```cpp\n#include \n#include \n#include \n#include \n#include \n\nint main() {\n // Sequence: a vector of cart quantities.\n std::vector cartQuantities = {2, 1, 3};\n\n // Associative sorted: product name to price, sorted by name.\n std::map catalog = {\n {\"USB Cable\", 9.99},\n {\"Mouse Pad\", 14.99},\n {\"Headphones\", 79.99}\n };\n\n // Unordered associative: set of viewed product IDs.\n std::unordered_set viewed = {101, 204, 555};\n\n // Adapter: queue of order IDs waiting to ship.\n std::queue shipQueue;\n shipQueue.push(\"ORD-1\");\n shipQueue.push(\"ORD-2\");\n\n std::cout << \"Cart items: \" << cartQuantities.size() << std::endl;\n std::cout << \"Catalog has Mouse Pad: \" << catalog.count(\"Mouse Pad\") << std::endl;\n std::cout << \"Viewed 204? \" << viewed.count(204) << std::endl;\n std::cout << \"Next to ship: \" << shipQueue.front() << std::endl;\n return 0;\n}\n```\n\n\nFour containers, four families, four very different internal layouts. The chapters that follow take each one apart so you can pick the right family for a given problem.\n\n---\n\n# Headers and the std Namespace\n\nEvery STL piece lives in a header named after the container, the algorithm group, or the utility. The headers don't have a `.h` extension; that's a C convention. C++ standard headers use no extension.\n\n\n| Header | Contains |\n|--------|----------|\n| `` | `std::vector` |\n| `` | `std::deque` |\n| ``, `` | `std::list`, `std::forward_list` |\n| `` | `std::array` (fixed-size) |\n| ``, `` | Sorted associative containers |\n| ``, `` | Hash-based associative containers |\n| ``, `` | `std::stack`, `std::queue`, `std::priority_queue` |\n| `` | `std::sort`, `std::find`, `std::copy`, etc. |\n| `` | `std::accumulate`, `std::iota`, `std::inner_product` |\n| `` | Iterator helpers (`std::back_inserter`, `std::advance`) |\n| `` | Function objects (`std::greater`, `std::function`, `std::bind`) |\n| `` | `std::pair`, `std::move`, `std::swap` |\n| `` | `std::tuple` |\n\n\nEverything in the STL lives inside the `std` namespace. You access it as `std::vector`, `std::sort`, `std::map`, and so on. The `::` is the scope resolution operator and it disambiguates \"the `vector` in the standard library\" from any `vector` you might define yourself.\n\n\n```cpp\n#include \n#include \n#include \n\nint main() {\n std::vector stock = {12, 7, 3, 0, 9};\n std::sort(stock.begin(), stock.end());\n\n for (int q : stock) {\n std::cout << q << \" \";\n }\n std::cout << std::endl;\n return 0;\n}\n```\n\n\nTwo `#include` directives, two `std::` qualifications. The `` header brings in `std::vector`; the `` header brings in `std::sort`. The qualified names make it obvious where each piece comes from.\n\nYou'll occasionally see `using namespace std;` at the top of files in tutorials. Don't do that in real code. It dumps every name from `std` into the global scope, which causes naming collisions (`std::distance`, `std::count`, `std::move`, `std::less` are all common words) and makes it harder to see where each symbol comes from. The cost of typing `std::` is small. The cost of debugging a collision in a large codebase is not.\n\n---\n\n# STL vs the C++ Standard Library\n\nYou'll hear people use \"STL\" and \"C++ standard library\" interchangeably. They're not the same thing, although the distinction matters less in 2026 than it did twenty years ago.\n\nThe original STL, the one Stepanov and Lee built at HP, contained four things: containers, iterators, algorithms, and function objects. That's the meaning the term has when someone says \"the STL design\". The C++ standard library is much broader. It includes everything in the STL plus `std::string`, the I/O streams in ``, the smart pointers in ``, the chrono library, the threading primitives, the filesystem library, and on and on. None of those are STL in the original sense, but they all live in `std::` and ship with every conforming compiler.\n\nIn casual usage, \"STL\" has drifted to mean \"anything in the standard library.\" Strictly speaking that's wrong; an `std::shared_ptr` is part of the C++ standard library but not part of the STL. For this section of the course, \"STL\" means the original four pillars, and that's the focus through every chapter here.\n\nOne practical consequence: when you read a job description that says \"strong knowledge of STL,\" they almost certainly mean the original-sense STL. Knowing every container, the iterator categories, and which algorithm fits each task is the actual ask. Knowing `std::string` and `` is taken for granted; those are taught in the first weeks of any C++ course.\n\n---\n\n# Properties the STL Guarantees\n\nBeyond \"you get containers and algorithms,\" the STL makes a handful of design promises that are worth knowing because they shape how you use the library.\n\nThe first is **value semantics**. Containers own their elements by value. Copying a `std::vector` deep-copies all its `int`s into a new buffer. Moving a vector (since C++11) transfers ownership of the buffer in O(1) without copying the elements. There's no implicit sharing, no reference counting, no GC. If you want shared ownership, you put `std::shared_ptr` into the container; the container itself stays a simple value.\n\n\n```cpp\n#include \n#include \n\nint main() {\n std::vector a = {1, 2, 3};\n std::vector b = a; // deep copy: b is independent of a\n b[0] = 99;\n std::cout << \"a[0]=\" << a[0] << \" b[0]=\" << b[0] << std::endl;\n return 0;\n}\n```\n\n\nModifying `b` doesn't affect `a` because `b` got its own copy of the elements at construction. Reference semantics would make `b[0] = 99` change `a[0]` too. Value semantics is the more predictable default and is the one C++ picks.\n\nThe second is **complexity guarantees**. The standard pins down the asymptotic cost of every container operation, not just for one implementation but for all conforming implementations. `std::vector::push_back` is amortised O(1) no matter which standard library you link against. `std::map::insert` is O(log n). `std::unordered_map::find` is O(1) on average. The standard is precise about which operations must hit a given bound, so portable code can rely on the guarantees.\n\nThe third is **exception safety**. STL operations come with documented exception safety levels, usually the **strong guarantee**: if an operation throws, the container is left in the state it was in before the call. Some operations weaken this to the **basic guarantee** (no resource leak, but the container may be in a different valid state). Knowing which is which matters when you're writing code that can throw mid-operation. The chapters that follow flag the exception-safety level of each operation that has a non-obvious one.\n\nThe fourth is **iterator and reference stability rules**. Every container documents exactly which operations invalidate iterators or references. The exact rules differ per container (`vector` invalidates everything on reallocation; `list` invalidates almost nothing; `map` invalidates only iterators to erased nodes), and getting them wrong is one of the most common sources of bugs. The container chapters spell out the rules.\n\n\n```mermaid\nflowchart LR\n A[STL guarantees]:::cyan --> B[Value semantics]:::orange\n A --> C[Complexity bounds]:::green\n A --> D[Exception safety]:::teal\n A --> E[Iterator stability rules]:::orange\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n```\n\n\nThe four guarantees layer up to give you a library where the costs are visible, the lifetimes are predictable, and the failure modes are explicit. None of them is unique to C++, but the combination is what makes the STL well-suited to systems work where performance and resource management matter.\n\n---\n\n# A Brief Word on Allocators\n\nEach STL container has a second template parameter, an **allocator**, that controls how the container obtains and releases memory. You don't see it most of the time because every container defaults to `std::allocator`, which calls `operator new` and `operator delete` under the hood.\n\n\n```cpp\n// What you write:\nstd::vector v;\n\n// What the compiler sees (default template arguments filled in):\nstd::vector> v;\n```\n\n\nFor 95 percent of code, the default allocator is correct and the parameter can be ignored. Allocators become interesting when you need custom memory management: a pool allocator for fast allocation of many same-sized objects, a stack allocator for tight loops, a shared-memory allocator for inter-process containers. For this section, treat the allocator parameter as a footnote and let it default.\n\n---\n\n# Putting It All Together\n\nA single line of typical STL code touches all four pillars at once. Here is a complete program that builds a product catalog, sorts it by price, and finds the first product over $30.\n\n\n```cpp\n#include \n#include \n#include \n#include \n#include \n\nstruct Product {\n std::string name;\n double price;\n};\n\nint main() {\n std::vector catalog = {\n {\"USB Cable\", 9.99},\n {\"Wireless Headphones\", 79.99},\n {\"Mouse Pad\", 14.99},\n {\"Keyboard\", 49.99}\n };\n\n // Sort by ascending price using a lambda as the comparator.\n std::sort(catalog.begin(), catalog.end(),\n [](const Product& a, const Product& b) {\n return a.price < b.price;\n });\n\n // Find the first product priced above $30.\n auto pricey = std::find_if(catalog.begin(), catalog.end(),\n [](const Product& p) { return p.price > 30.0; });\n\n std::cout << \"Sorted catalog:\" << std::endl;\n for (const auto& p : catalog) {\n std::cout << \" \" << p.name << \" $\" << p.price << std::endl;\n }\n if (pricey != catalog.end()) {\n std::cout << \"First over $30: \" << pricey->name << std::endl;\n }\n return 0;\n}\n```\n\n\nThe container is `std::vector`. The iterators come from `catalog.begin()` and `catalog.end()`. The algorithms are `std::sort` and `std::find_if`. The function objects are the two lambdas (one comparator, one predicate). Four pillars, one program, and the program reads like a paragraph because each piece does exactly one job and composes cleanly with the others.\n\n---\n\n# Common Misconceptions Worth Clearing Up\n\nA few ideas come up often and trip people up. Worth correcting before you start the per-container chapters.\n\n**\"STL containers are slow because they're generic.\"** They aren't. Generic in C++ means template-based, and templates are a compile-time mechanism. A `std::vector` produces the same machine code a hand-rolled int-array would, give or take what the optimiser sees. Benchmarks consistently show standard containers matching hand-written ones for the same task. The cases where the STL loses are usually about the wrong container choice (using a `list` when a `vector` would do), not about overhead in the container itself.\n\n**\"`std::vector` is just a C array with extra steps.\"** It's much more than that. A vector knows its size, manages its own buffer, handles reallocation, propagates exceptions correctly during construction, and integrates with every algorithm in ``. A C array is a fixed-size, manually-managed memory range with no introspection. The two have similar memory layouts but very different ergonomics.\n\n**\"All STL containers support all STL algorithms.\"** No. Algorithms are written against iterator categories, and not every container provides every iterator category. `std::sort` needs random-access iterators, which `std::list` doesn't have, so `std::sort(list.begin(), list.end())` doesn't compile. The next-chapter-but-one on iterator categories spells out the hierarchy and which algorithm needs which category.\n\n**\"You should use `std::list` whenever you insert in the middle.\"** Almost never. The cost of cache misses on a linked list traversal usually overwhelms the savings from avoiding shifts in a vector, for sizes up to thousands of elements. Measure before reaching for a list. The list chapter covers the actual trade-offs in detail.\n\n**\"The standard says `std::vector` doubles its capacity on growth.\"** The standard says capacity grows geometrically and `push_back` is amortised O(1). It does not mandate a specific factor. Libstdc++ and libc++ pick 2x; MSVC picks 1.5x. Production code shouldn't depend on the exact factor.\n\n**\"Using `using namespace std;` makes code cleaner.\"** It makes code shorter, not cleaner. Short names like `count`, `distance`, `move`, `less`, `swap`, `bind` collide with names you might want for your own functions or variables, and the collisions produce errors that are confusing to track down. Type the four characters; it's worth it.\n\n---\n\n# What's Coming in This Section\n\nNow that you have the map, here's the route through the next 23 chapters.\n\n- **Chapters 2-13** walk through the standard containers one family at a time: sequence containers first (`vector`, `deque`, `list`, `forward_list`, `array`), then sorted associative (`set`, `map`), then hashed (`unordered_set`, `unordered_map`), then adapters (`stack`, `queue`), then the small utility templates (`pair`, `tuple`, and the C++17 sum types `optional`, `variant`, `any`).\n- **Chapters 14-15** cover iterators in depth: how they work internally, the five iterator categories, and which algorithms each category supports.\n- **Chapters 16-20** cover algorithms: an overview chapter, then sorting, searching, modifying operations, and numeric algorithms.\n- **Chapters 21-23** cover function objects: writing your own, `std::function` for type-erased callables, and `std::bind` for partial application.\n\nEach chapter assumes you know what was covered in the previous ones. By the end you'll know which container to reach for, how to walk it, which algorithm to apply, and how to customise the algorithm's behaviour.\n\n---\n\n# Summary\n\n- The STL is the part of the C++ standard library that provides generic containers, iterators, algorithms, and function objects, designed by Alexander Stepanov and standardised in C++98.\n- The four pillars are containers (store data), iterators (walk data), algorithms (operate on iterator ranges), and function objects (customise algorithm behaviour).\n- Containers fall into four families: sequence (`vector`, `deque`, `list`, `forward_list`, `array`), sorted associative (`set`, `map`), unordered associative (`unordered_set`, `unordered_map`), and adapters (`stack`, `queue`, `priority_queue`).\n- Templates make the library generic at compile time. There's no runtime indirection, no boxing, and no slowdown compared to hand-written code, at the cost of compile time and binary size.\n- The key design decision is that algorithms operate on iterators, not on containers directly. This makes the number of pieces grow as containers plus algorithms instead of containers times algorithms.\n- Each STL piece lives in a header named after it (``, ``, ``, ``, ``, ``, ``, ``). Everything is in the `std::` namespace, and `using namespace std;` is best avoided.\n- A single line like `std::sort(prices.begin(), prices.end(), std::greater{});` touches all four pillars, which is the library's signature usage pattern.\n\nThe next chapter starts the tour of containers with `std::vector`, the workhorse of the sequence family and the default choice for a growable collection of elements.","pageType":"cpp"}

STL Overview

Get Premium