C++ Patterns
Use this skill for day-to-day modern C++ (C++20+) with a bias for safety, clarity, and maintainable APIs.
If your primary task is test architecture/debugging, activate cpp-testing alongside this skill.
When to activate
- Writing new C++ modules/libraries/services
- Reviewing PRs for ownership, lifetime, and exception safety
- Refactoring for cleaner interfaces and fewer footguns
- Introducing RAII, smart pointers, and standard library algorithms
Outcome expectations
- APIs encode ownership and lifetime intent directly in types.
- Resource cleanup is deterministic (RAII) and exception-safe.
- Error behavior is consistent per layer (no mixed ad-hoc strategy).
- Concurrency code has explicit stop/cancellation and race-checking plan.
Core rules (high signal)
- Prefer RAII for resource ownership; avoid raw
new/delete. - Use value types by default; use references/pointers to express optionality and non-ownership.
- Use
std::unique_ptrfor exclusive ownership;std::shared_ptronly when shared ownership is required. - Prefer standard algorithms over hand-written loops when it improves clarity.
- Keep APIs small; make invalid states unrepresentable where feasible.
- Define clear error strategy: exceptions vs
std::expected-style returns vs status codes.
Recommended workflow
- Clarify ownership and lifetime boundaries first (handles, buffers, views, async captures).
- Design the public API around value semantics and explicit contracts.
- Implement with RAII wrappers and Rule-of-Zero defaults.
- Add warnings/sanitizers/static analysis early in the build.
- Review for footguns (dangling views, iterator invalidation, detached threads).
Quick review checklist
- Ownership is explicit (who allocates, who frees)
- No leaks or dangling refs (temporaries,
string_view, iterator invalidation) - Rule of Zero is used; special members defined only when needed
constcorrectness is consistent- No surprising implicit conversions; use
explicit - Concurrency code has a cancellation/stop strategy
- Error semantics and exception guarantees are documented
Common anti-patterns to reject
- Owning raw pointers in public APIs
- Returning/storing
std::string_viewtied to temporary storage - Detached threads that capture
thiswithout a lifetime model - Broad
catch (...)blocks that hide failure context - Exposing mutable shared state without synchronization policy
Resources
Load on demand:
references/ownership-raii.md— ownership rules, RAII patterns, smart pointers, lifetimereferences/core-guidelines.md— distilled C++ Core Guidelines pointersreferences/api-design.md— interface design, value semantics, error strategyreferences/concurrency.md— jthread, mutex, atomic, condition_variable, stop_token, race detectionreferences/tooling-build.md— compiler warnings, sanitizers, static analysis, binary inspection (MinGW/objdump, MSVC/dumpbin, Linux tools), CMake hygiene