# AnthonyCalandra/modern-cpp-features: A Version-by-Version C++ Cheatsheet > The repository is a reference index of C++11 through C++23 language and library features, split across version files. It is a lookup table for engineers who already know C++ and need to check what landed in which standard, not a tutorial. **AnthonyCalandra/modern-cpp-features** — A cheatsheet of modern C++ language and library features. - Repository: https://github.com/AnthonyCalandra/modern-cpp-features - Stars: 21,894 · Forks: 2,263 - Language: Unknown - License: MIT - Published: 2026-09-21 · Updated: 2026-09-21 · Language: en - Canonical page: https://hysenlabs.com/projects/anthonycalandra-modern-cpp-features ## What modern-cpp-features actually indexes The repository answers one narrow question: which C++ standard introduced a given language or library feature. Its README is an index of feature names grouped under C++23, C++20, C++17, C++14 and C++11, each name linking to an anchor. The top-level directory holds CPP11.md, CPP14.md, CPP17.md, CPP20.md and CPP23.md, so the explanations behind those links live in per-version files rather than in the README itself. The README states its scope in the title: "C++23/20/17/14/11". The audience is engineers who already write C++ and need to check a boundary. If you are deciding whether a codebase can drop its C++17 fallback for std::optional, or whether a reviewer's claim that constexpr if is C++17 is correct, this is the kind of reference you open for thirty seconds and close. It is not a teaching resource. There are no exercises, no build instructions and no discussion of why a feature was added. The topics listed on the repository are cpp, cpp11, cpp14, cpp17, cpp20 and cpp23, which matches the file layout. Nothing in the README covers C++26, so treat the index as ending at C++23. ## How the version files and README index relate The data flow is manual and one-directional. A contributor adds a feature to the appropriate CPPxx.md file, then adds a matching bullet and anchor link to the README index for that version. The README groups entries under two headings per standard, "new language features" and "new library features", so a reader scanning the index sees the split before opening the detail file. That structure has a consequence worth naming. The README and the version files are separate artifacts with no generator between them. A feature can be documented in CPP20.md and missing from the README index, or the reverse. The repository ships a CONTRIBUTING.md, but the README shows no automated check that the index and the detail files agree, so the consistency burden sits with reviewers. Anchors are derived from feature names, and several contain characters that need escaping in the link target. The README shows this for [\[\[likely\]\] and \[\[unlikely\]\] attributes](#likely-and-unlikely-attributes) and for [\[\[deprecated\]\] attribute](#deprecated-attribute). Anyone editing the index has to keep the visible label and the anchor in sync by hand. ## No install step: reading the cheatsheet from a local checkout There is no package to install. The repository is Markdown, so the practical setup is having the files locally and reading or searching them. The README gives no install instructions, so there is no project-specific command to copy here; the files to open are the ones listed at the top level. The checkout should contain CONTRIBUTING.md, CPP11.md, CPP14.md, CPP17.md, CPP20.md, CPP23.md, LICENSE and README.md. If CPP23.md is absent, you have an older copy. A first real use is checking whether a feature you are about to use exists in the standard you target. Open the version file for that standard rather than the README index, because the detail files carry the anchors the index links to. For a C++23 question, CPP23.md is the file to read; for a question about std::optional or std::variant, CPP17.md is the one. If you want the index view instead, read the README and follow the anchor into the version file. None of this needs a compiler, which is the point of the repository: it is a reading aid, not a build dependency. ## Where the cheatsheet stops being enough The repository records that a feature exists in a standard. It does not record whether your compiler implements it. There is no table of GCC, Clang or MSVC versions, and the README shows no per-feature implementation notes. A feature listed under C++20 may be absent from the toolchain in front of you, and this repository will not tell you that. The per-version files are also not a substitute for the standard text when behaviour is subtle. The README index for C++23 lists increasing range-based for safety, deducing this and the multidimensional subscript operator as separate bullets, which is enough to know they exist but not enough to reason about lifetime or overload resolution. For those questions you need cppreference or the working draft. Contributions are manual, so coverage is uneven across versions. The C++11 and C++17 lists in the README are long and granular; C++23 has four language features and eight library features listed. That asymmetry may reflect reality, but it also means the newest file is the thinnest, and it is the one most likely to be consulted by someone on a current toolchain. ## cppreference as the alternative, and when to prefer it The obvious alternative is cppreference.com. The difference is structural rather than editorial. cppreference is organised around individual entities: one page per type, function or language construct, each carrying a version history table, compiler support notes and a formal specification reference. This repository is organised around standards: one file per C++ version, each listing feature names with short explanations and no per-compiler data. That makes the two tools answer different questions. "What is the exact overload set for std::midpoint?" belongs on cppreference. "Which standard added std::midpoint?" is faster here, because the answer is the file you are already reading. A second alternative is a compiler's own feature-test macro documentation, which answers the implementation question this repository never addresses. The trade-off is real: this repository is lighter to scan and weaker on precision. If you find yourself opening it twice for the same feature and still needing cppreference, you have picked the wrong tool for that question. ## Maintenance, licence and the cost of keeping up The repository is not archived. Its last push was on 2026-06-09, which is recent enough that the index reflects the C++23 material listed in the README. There are no releases, so there is no versioned artifact to pin; you consume the default branch, master, at whatever state it is in when you copy it. Upgrade cost is therefore zero in the dependency sense and non-zero in the trust sense. Because there is no release process, there is no changelog to read before pulling in changes. An update may change anchors, rename sections or add entries to a version file, and any internal links your team keeps into the repository can break. If you mirror the content, pin a commit rather than tracking master. The licence is MIT, stated in the LICENSE file at the top level. MIT permits reuse and modification with the copyright notice and permission notice retained. That is a permissive arrangement, but it says nothing about the accuracy of the content, and the README carries no warranty statement beyond what the licence text itself provides. If you republish the tables internally, keep the notice. ## Who this reference is for Use it if you move between standards regularly, review code from teams on different toolchains, or need a fast answer to "is this C++17 or C++20?" without leaving your editor. The per-version file layout makes it searchable, and the README index gives a quick scan of what each standard added. Do not use it as your only C++ reference. It has no compiler support matrix, no formal wording and no guidance on when a feature is the wrong choice. It also will not help someone learning the language: the entries assume you already understand move semantics, templates and the type system well enough to know why a feature matters. If you maintain a fork or an internal copy, the thing to watch is the gap between the README index and the CPPxx.md files, since the README shows no mechanism that enforces alignment between them. ## Conclusion Adopt this if you regularly need to answer "which standard introduced this?" and you want a single repository to grep instead of a search engine. Skip it if you are learning C++ or need compiler-specific guidance: the repository has no build files, no tests and no per-compiler notes, and the README does not document how the per-version files are validated. Before relying on it, open CPP23.md and CPP20.md and confirm the entries you care about are present, because the README index and the version files are separate documents that can drift. ## FAQ ### What is the difference between C++ and modern C++? The repository does not define the term directly, but its structure shows the split it uses: features are grouped by the standard that introduced them, from C++11 through C++23, with each version's language and library additions listed separately. So "modern C++" here means the feature sets of C++11 and later, not the pre-2011 language. ### Is modern-cpp-features still updated? The repository is not archived, and its last push was on 2026-06-09. There are no releases, so the default branch master is the only thing to consume. ### Does modern-cpp-features document C++26 features? No. The README and the top-level files cover C++23, C++20, C++17, C++14 and C++11 only, and the listed topics stop at cpp23. ### How do I check which C++ version a feature belongs to in modern-cpp-features? Open the per-version file, for example CPP23.md for std::expected, or look up the feature name in the README index and follow its anchor into the matching CPPxx.md file. The README groups entries under new language features and new library features for each standard. ### What licence does modern-cpp-features use? MIT, per the LICENSE file at the top level of the repository. The licence permits reuse and modification provided the copyright and permission notices are retained. ### Can I use modern-cpp-features to check compiler support? No. The repository lists which standard introduced a feature but contains no compiler version table or per-implementation notes, so it cannot tell you whether your GCC, Clang or MSVC build supports a given entry. ## Sources - [AnthonyCalandra/modern-cpp-features on GitHub](https://github.com/AnthonyCalandra/modern-cpp-features) - [Issues](https://github.com/AnthonyCalandra/modern-cpp-features/issues) - [License: MIT](https://github.com/AnthonyCalandra/modern-cpp-features/blob/master/LICENSE) - [README](https://github.com/AnthonyCalandra/modern-cpp-features/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/anthonycalandra-modern-cpp-features