Tools

Use this page as the top-level map for the toolchain-oriented links in this section.

Tool categories

• Compilers and online experimentation: Compiler Explorer, Quick Bench, Wandbox, and other fast ways to test ideas.
• Build systems and package managers: CMake, vcpkg, Conan, Meson, and dependency workflow references.
• Code quality and debugging: clang-tidy, clang-format, sanitizers, and include hygiene tools.
• Testing and benchmarking: GoogleTest, Catch2, doctest, benchmark workflows, and related references.

Recommended starting points

• Start with Compiler Explorer when you need a zero-setup place to validate code or inspect generated assembly.
• Start with CMake documentation if you are wiring up a real project or trying to understand target-based builds.
• Start with clang-tidy and AddressSanitizer when you want fast feedback on correctness and maintainability.
• Start with GoogleTest or Catch2 when you need a practical unit-test harness.

When to use which tool page

• Use the compiler page for quick experiments, generated code inspection, and benchmark prototypes.
• Use the build page when the main question is dependency management, configuration, or reproducible builds.
• Use the quality page when you want static analysis, formatting, sanitizer coverage, or header cleanup.
• Use the testing page when you are choosing a test framework or lightweight performance measurement setup.

Tool adoption order

1. Start with a compiler and a reproducible build flow.
2. Add formatting so style noise stops distracting from code review.
3. Add static analysis and sanitizers to catch correctness issues early.
4. Add tests and benchmarks once the project has behavior worth protecting and measuring.

Fast tool-choice questions

• need to validate syntax, assembly, or a tiny idea quickly: go to compiler and experimentation tools
• need to make a real project build repeatably: go to build systems and package managers
• need to catch crashes, UB, style drift, or suspicious code: go to quality and debugging tools
• need to protect behavior or compare performance changes: go to testing and benchmarking tools

Troubleshooting workflow

1. Reproduce the problem in the smallest possible build or code sample.
2. Decide whether the problem is compilation, configuration, correctness, or regression.
3. Use the matching tool page instead of adding tools randomly.
4. Bring the fix back into the main project only after the smallest case is understood.

When to start here

• you are setting up a new C++ project and need an order for adopting tools
• you inherited a project with ad hoc scripts and want to make the toolchain more systematic
• you need a map of which page answers build, quality, testing, or quick-experiment questions fastest