Skip to content

Test mode: data may occasionally be reset.

User Guide

C++ idioms are established patterns and techniques that experienced C++ developers use to solve common problems correctly and idiomatically. This site collects, explains, and tracks them — including which language standards they apply to, whether they have been superseded by newer language features, and how their use is debated in the community.

Table of Contents

Reading an idiom page

Each idiom page is divided into the following sections:

Intent — A single sentence summarising what the idiom achieves. Read this first to decide whether the idiom is relevant to your situation.

Motivation — Why you would reach for this idiom: the problem it solves, the pitfalls it avoids, and the context in which it arises.

Solution — How the idiom works mechanically. This section describes the structure of the code, the invariants it relies on, and why the approach is correct.

Trade-offs — Costs, limitations, and situations where the idiom is a poor fit. A good idiom is not always the right tool; this section helps you decide.

Code examples — Annotated with the C++ standard version they require. Examples may cover a range of standards (e.g. C++11..C++20) when the idiom applies across multiple revisions of the language. Every example has a Run or Compile button — Run compiles and executes the code via Compiler Explorer and shows its output; Compile (for examples that are about compile-time behaviour and have nothing to execute, like type traits or static_assert) just reports whether it compiles and shows any diagnostics. An example that isn't actually a complete, self-contained program will simply show a compile error when you try it. Every example also has an Open in Compiler Explorer link, which opens the same source on godbolt.org itself (compiled with -O3, for readable assembly) for further exploration — viewing assembly, trying other compilers, and so on.

Known uses — Links to real open-source projects known to use the idiom, each with an optional short note on how it's used there.

Originators and References link to their own pages, listing every other idiom credited to that person or citing that source.

Status badges

Every idiom carries a status badge indicating its current relevance. Hover over any status badge to see a fuller explanation.

Badge Meaning
proposed Someone believes this is a genuine idiom, but it isn't yet in widespread use or agreed upon by the broader C++ community. Shown by default alongside established idioms — see Contributing — with a checkbox to hide it if you'd rather see only settled ones.
current Widely applicable and recommended for modern C++.
debated The idiom's validity or applicability is contested. Read the trade-offs carefully.
superseded Replaced by another idiom or a standard language feature. The page links to the replacement.
obsolete No longer recommended; may still appear in older codebases.
legacy Still usable, but rarely used directly — compilers or libraries often hide its use internally. Not obsolete, just uncommon to write by hand.
draft Work in progress — content may be incomplete or under review.

Proposed is about the idiom's standing in the community, not the page's completeness — a Proposed idiom's page can be just as thorough as a Current one; it's simply not yet established. That's different from draft, which is purely about whether the page itself is finished.

A superseded idiom may link either to another idiom on this site or directly to the WG21 proposal (P-number or N-number) that introduced the replacement language feature.

C++ standard badges

The blue badge on an idiom page shows which C++ standard revision(s) the idiom applies to. A range such as C++11..C++20 means the idiom was introduced with C++11 and remained the recommended approach through C++20.

Clicking the badge takes you to the official standard document or draft for that revision, if the site admin has configured one for that standard — otherwise the badge is plain text.

Categories and tags

Categories are hierarchical and reflect the design or problem domain — for example Resource Management → Memory. Browse the full tree from Categories in the top navigation bar.

Tags (the #tag links at the bottom of each page) are flat keywords useful for cross-cutting concerns that do not fit neatly into the category hierarchy. Browse every tag in use, with how many idioms carry it, from Tags in the top navigation bar.

People

Idioms are often associated with the person or people who originated or popularised them. Their name, a short bio, and any links (homepage, talks, papers) appear on the idiom page and on their own profile page.

If your account is linked to a person record — for example, because you are that person — you can edit that record's own bio and links yourself from Account Settings, without needing an admin to do it for you.

The Related Idioms section lists idioms that are closely connected — either because they solve similar problems, compose with each other, or are commonly discussed together, grouped by kind — for example Alternative to, Combines with, or Prerequisite for. Kinds can be directional: if idiom A lists idiom B as a Prerequisite for, B's page shows A grouped under Builds on. A plain, untyped relation just shows as Related on both idioms. Hover over a group's label to see what that relationship means, or see the full list of kinds at Relation Kinds.

Idioms that have not been written yet appear as not yet written. If you are logged in as a contributor, clicking the name opens the editor pre-filled with a template for that idiom. If you are not logged in, the name appears as plain text. The link in either case signals that the connection exists and is waiting to be documented — and resolves automatically once that idiom is created.

References

Idioms can cite books, papers, conference talks, and articles from a shared bibliography — cite the same book from ten idioms and it's still one entry, edited in one place at References. Contributors can add new references directly; each entry can carry authors, a year, an ISBN, a link, and a video link for recorded talks.

Version history

Every edit to an idiom, category, reference, or person is recorded. You can browse the full history from the Version history button on any of these pages. The diff view shows a field-by-field comparison between any two versions, making it easy to see what changed and when.

Version history is public — no account required to view it. Restoring or deleting an old version is more restricted, matching how each entity is already edited elsewhere on the site: idioms use the same maintainer permissions as editing them; references can be restored or deleted by any Contributor; categories and people require an Admin.

Deleting an idiom (admin-only) hides it from the site rather than erasing it — its version history is kept in full and an admin can restore it at any time.

Watching idioms

If you have an account, you can Watch any idiom to receive notifications when it is updated or when new comments are posted. The bell icon in the navigation bar shows your unread notification count.

You can also Watch a category or a person. Those work differently: instead of tracking edits to the category or person page itself, you're notified whenever a new idiom appears there — added to the category, or crediting that person as an originator.

Account Settings controls whether — and when — those also become emails: Immediately (one email per update), a daily digest (everything bundled into one email a day, at whatever local time and time zone you choose), or Never (in-app notifications only). Switching to a digest doesn't lose anything in between digests — Pending Digest always shows exactly what your next one will contain, and doubles as a to-do list: Mark done on any item removes just that one from the digest without waiting for it to send. Once you're on a digest, Pending Digest appears in your account menu (click your name, top right) for quick access.

Don't want an account? An RSS feed of recently published and updated idioms is available at /feed.xml, linked in the footer of every page.

Discussion

Each idiom has a Discussion page where you can ask questions, point out errors, or suggest improvements. Log in to post a comment.

You can quote another comment using the Reply button, and mention other users by writing @username to notify them directly.

If you're a New Contributor (see Contributing below), your comments are reviewed before they appear, same as your idiom edits — once you're promoted to Contributor, comments post immediately.

Reporting content

If you spot something that shouldn't be there — spam, abuse, a broken or malicious link, off-topic content — click Report on the idiom, category, reference, person, comment, or user profile in question. You'll need to be logged in, but any account can report; describe what's wrong (Markdown supported) and a moderator will review it.

If someone else already reported the same thing, your report is added as supporting detail to the existing case instead of creating a duplicate. You can track the outcome of anything you've reported from My Reports in your account menu — you'll also get a notification once a moderator resolves or dismisses it.

Reporting flags content for review; it doesn't change or remove anything by itself. See the Moderation Guide for what counts as reportable.

Account and profile

You can register with an email address and password, or sign in instantly with your Google or GitHub account — either way you get the same access described below. Email/password accounts need a one-time activation link sent to your inbox before you can log in — that link expires 48 hours after you register, and if it's not used by then the registration is deleted automatically, so you'd need to sign up again; forgotten your password? Use Forgot password on the login page to get a reset link.

From Account Settings you can change your display name, set a public bio and links, and (if you signed up with a password) change it. Changing your password (here or via a reset link) also signs you out everywhere else it's currently logged in — useful if you think someone else got hold of it. Your account settings page also shows a link to your public profile (/u/{your account id}), which anyone can view — it shows your bio, links, and member-since date.

Deleting your account (from Account Settings) removes your email, password, avatar, bio, and links immediately. Comments and edit history you've contributed remain, attributed to a generic "deleted user" placeholder, so other people's discussions and the idiom edit history stay intact.

Two-factor authentication is available to anyone from Account Settings — scan the QR code with an authenticator app (Google Authenticator, 1Password, Authy, etc.), confirm one code, and save the one-time backup codes it shows you. It's required for moderators and admins: if your account is promoted to one of those roles, you'll be asked to set it up the next time you try to use a moderator/admin page. Lost your device and your backup codes? Ask an admin to reset it for you.

Contributing

To add or edit idioms, create an account. New accounts start as a New Contributor: your submissions are reviewed before they go live. Once a moderator or admin has approved a few of your submissions, you're promoted to Contributor and future edits publish immediately. If a submission needs changes, you'll be notified with the reviewer's notes and can revise it from My Submissions in your account menu.

If you notice an error or have a suggestion but do not want to edit directly, use the Discussion page on the relevant idiom.

All content on this site — idiom pages, the Guide, and comments — is published under CC BY-SA 4.0. By contributing, you agree your contribution is licensed on the same terms.

What contributors can do

Once you're promoted from New Contributor to Contributor, changes publish immediately:

  • Create and edit idioms from the admin dashboard at /admin, including adding code examples, tags, related-idiom links, known uses, and reference citations.
  • Add new categories, people, and references — propose a new category, originator, or bibliography entry right from their respective admin pages.
  • Post comments on any idiom's Discussion page without waiting for review.

What's admin-only

To keep the category tree, tag list, C++ standards list, and relation kinds consistent site-wide, a few structural actions are restricted to admins:

  • Renaming an idiom — click the rename toggle next to any idiom name on the dashboard. The slug updates automatically and the change is recorded in the idiom's version history.
  • Renaming or deleting a category.
  • Renaming a tag across every idiom that carries it (tags themselves are just free-text words you type when editing an idiom — anyone can add a new one that way; only the bulk-rename tool is admin-only).
  • Editing or deleting an existing person record (unless it's linked to your own account — see People above).
  • Adding, editing, or removing entries in the C++ standards list.
  • Adding, editing, or removing entries in the Relation Kinds list used by related: in idiom frontmatter.
  • Deleting a reference (editing one's details is open to all contributors).

If you'd like a taxonomy change made, ask an admin, or start a conversation on the relevant idiom's Discussion page.

Admins and moderators review the queue of pending submissions from new accounts at Moderation in the nav. Admins can also review a log of structural actions — plus idiom deletions and restores, user suspensions, and taxonomy changes — at Activity in the admin dashboard.

Review exists to catch content that's factually wrong, off-topic, spam, or in breach of the Code of Conduct — not to gatekeep differences of taste or technical opinion. See the Moderation Guide for the full policy, including where a disagreement belongs when nothing is actually wrong.

Editing tools

The idiom editor autocompletes as you type: start typing an idiom name under related:, a status under status:, or a relation kind:, and a dropdown of valid values appears (press Ctrl+Space to trigger it manually). Hovering over a status: or kind: value also shows its full description after a short delay.

Inside Motivation, Solution, or Trade-offs, you can link to other content directly from the prose using double brackets: [[Idiom Name]] links to another idiom, [[category:Name]] to a category, [[reference:Title]] to a reference, and [[person:Name]] to a person. An idiom name that doesn't match anything yet renders as "not yet written", the same as an unresolved entry under related:.

related: and inline [[Name]] links both connect idioms, but serve different purposes: use related: for a connection worth surfacing on its own in the page's Related Idioms section (and it works both directions — see Related idioms above); use [[Name]] when you're just referencing another idiom while explaining something in the prose, without necessarily adding it to that list.

Inside a code example, wrapping part of it in // show-start and // show-end lets you write a complete, compilable example — includes, a main, any boilerplate needed — while only showing the interesting part(s) on the idiom page. Use as many // show-start/// show-end pairs as you like; everything outside them still compiles (and runs) but stays out of view. An example with no markers is shown in full, exactly as before — markers only control what's shown, not whether the Run/Compile button appears (see Reading an idiom page above); every example gets one regardless.

If someone else saves changes to the same idiom, category, reference, or person while you're editing it, your save is blocked rather than silently overwriting theirs — you'll see a message asking you to check what changed before saving again. For idioms, your own draft stays right there in the editor when this happens, so nothing you wrote is lost; save again once you've seen the current version.

Last updated 2026-07-26 by Recovery Admin