If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/Light-City/CPlusPlusThings shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Missing license — unclear to depend on

• Last commit 8w ago
• 26+ active contributors
• Tests present
• ⚠ Concentrated ownership — top contributor handles 66% of recent commits
• ⚠ No license — legally unclear to depend on
• ⚠ No CI workflows detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live Light-City/CPlusPlusThings repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/Light-City/CPlusPlusThings.

What it runs against: a local clone of Light-City/CPlusPlusThings — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in Light-City/CPlusPlusThings | Confirms the artifact applies here, not a fork | | 2 | Default branch master exists | Catches branch renames | | 3 | Last commit ≤ 87 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of Light-City/CPlusPlusThings. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/Light-City/CPlusPlusThings.git
#   cd CPlusPlusThings
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of Light-City/CPlusPlusThings and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "Light-City/CPlusPlusThings(\\.git)?\\b" \\
  && ok "origin remote is Light-City/CPlusPlusThings" \\
  || miss "origin remote is not Light-City/CPlusPlusThings (artifact may be from a fork)"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 87 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~57d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/Light-City/CPlusPlusThings"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

CPlusPlusThings is a comprehensive learning repository covering C++ concepts from beginner to advanced levels, with 368KB of C++ source code organized into modular topics (abstract classes, const correctness, bit manipulation, polymorphism, etc.). It serves as both an educational resource and interview preparation guide, structured around the Bazel build system with executable examples for each concept. Single-repo monolith organized by C++ concept domains: basic_content/{abstract,assert,bit,const,c_poly}/ with nested subdirectories for progressively complex examples (e.g., const/class_const/{first_example,overload_example,static_example}/). Each topic has BUILD file (Bazel), README.md, and multiple .cpp/.h files demonstrating variations. Top-level WORKSPACE indicates Bazel workspace root.

C++ learners progressing from foundational concepts to advanced topics, job interview candidates preparing for C++ technical assessments, and developers studying STL internals, concurrency patterns, and modern C++ features (C++11/14/17/20). The repo is primarily in Chinese but serves a global audience via bilingual documentation.

Actively maintained with structured organization (60+ documented subdirectories), multilingual README, and video learning series on Bilibili. Build infrastructure uses Bazel with proper BUILD files throughout. However, commit recency and comprehensive test coverage details are not visible in provided metadata—appears to be a mature educational project rather than production library.

Single-author maintenance risk (個人公眾號 by Light-City). No visible CI/CD pipeline configuration (.github/workflows absent). Risk of stale example code for C++11-era concepts without active refresh. Dependency on Bazel may create friction for contributors unfamiliar with that build system. No visible issue tracker snapshot provided.

Actively promoting video-based learning with recent Bilibili series (涉及 HashTable, enable_shared_from_this, C++11 thread/C++20 jthread). Supporting multiple run methods: Bazel+VSCode, Docker (xingfranics/cplusplusthings:latest), and g++. Public blog sync ongoing at light-city.github.io. 重磅项目 (flagship projects) linked in README suggest ongoing real-world application work.

git clone https://github.com/Light-City/CPlusPlusThings.git && cd CPlusPlusThings && bazel build //basic_content/const/class_const/first_example:all && bazel run //basic_content/const/class_const/first_example:main. Alternatively: docker pull xingfranics/cplusplusthings:latest && docker run -it xingfranics/cplusplusthings:latest. Or compile directly: cd basic_content/const/class_const/first_example && g++ -std=c++11 main.cpp apple.cpp -o main && ./main

Daily commands: Via Bazel: bazel run //basic_content/<topic>/<example>:<target> (e.g., bazel run //basic_content/abstract:abstract). Via Docker: docker run xingfranics/cplusplusthings:latest. Via g++ directly: navigate to example dir, compile with g++ -std=c++XX *.cpp, run binary. VSCode + Bazel extension recommended per README.

• basic_content/const/class_const/first_example/main.cpp: Foundational const member function and const object example—the canonical entry point for understanding const correctness in classes
• basic_content/abstract/abstract_base.h: Defines pure virtual interface pattern used throughout C++ design examples; critical for understanding polymorphism foundation
• WORKSPACE: Root Bazel workspace configuration; essential for understanding build system and dependency resolution across all examples
• basic_content/const/class_const/overload_example/apple.cpp: Demonstrates const vs non-const method overloading—a subtle but crucial concept for modern C++ API design
• basic_content/c_poly/c_examp.c: Shows C-style polymorphism via function pointers as contrast to C++ virtual methods—bridges C and C++ understanding
• README.md: Primary entry point; contains learning path, multiple execution methods, links to video tutorials and online knowledge base

New contributors should: (1) Add concept example under basic_content/<concept>/<example_name>/ with main.cpp, header.h, BUILD file; (2) Update basic_content/<concept>/README.md with explanation; (3) Follow existing Bazel target pattern in BUILD files (cc_library + cc_binary). See basic_content/const/class_const/first_example/ as template. Submit PR against main branch.

Bazel build requires proper setup (not trivial for g++ users); examples assume C++11 minimum (std=c++11 flag required in direct g++ compilation). Docker image (xingfranics/cplusplusthings:latest) may have stale dependencies—version pinning recommended. Chinese README is primary; English version may lag updates. No visible CI ensures examples compile consistently—manual testing required before contribution merge. const examples use mutable keyword which can confuse learners about true const semantics.

• const correctness — Pervasive throughout this repo (basic_content/const/ is foundational); prevents accidental mutation and documents API contracts—essential for writing safe, maintainable C++ code
• pure virtual functions and abstract base classes — Core to C++ polymorphism (basic_content/abstract/); enables interface-based design and substitutability principles fundamental to OOP
• virtual function dispatch and vtable mechanisms — Underlying mechanism for C++ runtime polymorphism; critical for understanding performance implications and memory layout when using inheritance
• CRTP (Curiously Recurring Template Pattern) — Alternative to virtual functions for compile-time polymorphism; increasingly important in modern C++ for zero-overhead abstraction
• move semantics and rvalue references — C++11 feature enabling efficient resource transfer (key to concurrency section); transforms performance characteristics of containers and smart pointers covered in this repo
• enable_shared_from_this — Specific advanced pattern highlighted in repo's video series (period 4); essential for safe shared ownership in multithreaded code
• bitwise operations and bit manipulation — basic_content/bit/ section covers low-level efficiency techniques; critical for systems programming, embedded contexts, and interview algorithmic problems

• isocpp/CppCoreGuidelines — Official C++ best practices and idioms reference; complements this repo's educational examples with authoritative guidance on const correctness, memory safety, and modern patterns
• AnthonyCalandra/modern-cpp-features — Comprehensive breakdown of C++11/14/17/20 features with code examples; directly overlaps with this repo's C++2.0 section and provides alternative explanations
• microsoft/STL — Official Microsoft C++ Standard Library implementation; essential for understanding STL internals that this repo covers in 'STL源码剖析' section
• torvalds/linux — Production C codebase showing polymorphism patterns via function pointers (related to basic_content/c_poly examples); demonstrates real-world C idioms contrasted in this repo
• chriskohlhoff/asio — Mature C++ concurrency library using modern patterns; directly applicable to this repo's 'C++ Concurrency in Action' and threading sections for advanced learners

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Create comprehensive BUILD files for all basic_content subdirectories and add bazel build verification

The repo claims to support Bazel (WORKSPACE file exists, many BUILD files present), but coverage is incomplete. Several subdirectories like basic_content/decltype lack BUILD files, making it impossible to build those examples via bazel. This breaks the documented 'vscode + bazel' workflow mentioned in README. Adding missing BUILD files and testing the full build chain would ensure the primary build method works end-to-end.

• [ ] Audit all subdirectories in basic_content/ to identify missing BUILD files (e.g., basic_content/decltype)
• [ ] Create BUILD files for each subdirectory following the pattern established in existing BUILD files (e.g., basic_content/const/BUILD)
• [ ] Run 'bazel build //basic_content/...' to verify all targets compile
• [ ] Add a GitHub Actions workflow (.github/workflows/bazel-build.yml) to catch future BUILD file breakage

Add README.md files with explanations for incomplete sections (decltype, and others)

The file structure shows basic_content/decltype exists but has no README.md, unlike sibling directories (abstract, assert, bit, c_poly, const all have README.md). These READMEs are crucial for learning as they explain concepts and examples. This inconsistency breaks the learning experience and wastes contributor effort on code that isn't documented.

• [ ] Identify all basic_content/* directories missing README.md files
• [ ] For decltype, write a README.md explaining: decltype keyword, use cases (e.g., template deduction), and link each .cpp example to the concept it demonstrates
• [ ] Follow the structure/format of existing READMEs (e.g., basic_content/const/README.md) for consistency
• [ ] Repeat for any other undocumented subdirectories to ensure 100% coverage

Add g++ compilation scripts for each basic_content section to support the documented 'g++' build method

README lists '方式3: g++' as a supported build method, but the repo only provides Bazel BUILD files. Contributors wanting to compile with g++ directly have no guidance. Adding shell scripts (e.g., compile.sh) in each directory would document explicit compilation commands, reduce onboarding friction, and serve as a fallback for users without Bazel installed.

• [ ] Create compile.sh scripts in each basic_content subdirectory that demonstrates how to build examples with g++
• [ ] For example, basic_content/const/compile.sh should show how to compile all const examples (const_num.cpp, const_function.cpp, and subdirectory examples)
• [ ] Include comments explaining flags and dependencies (e.g., -std=c++11 for c++11_example)
• [ ] Test scripts on a fresh clone to ensure they work without Bazel/WORKSPACE setup

• Add C++17 structured bindings examples under new basic_content/cpp17/ directory with const reference forwarding patterns—expand modern C++ coverage beyond C++11
• Create comprehensive test suite under tests/ using Catch2 or Google Test for existing basic_content examples to ensure const correctness and polymorphism behavior—currently no visible test coverage
• Translate key README sections and in-code comments to English and maintain parity—README_EN.md exists but file structure is documented in Chinese only, blocking non-Chinese contributors

This is an educational C++ learning repository with low security risk. The codebase is primarily educational material focused on teaching C++ concepts rather than production code. No hardcoded credentials, SQL injection vectors, or XSS risks were identified in the file structure. The main security consideration is that educational code examples may not follow production security best practices. Users should be aware that examples are for learning purposes and should not be directly copied into production systems without security review. The repository itself poses minimal security risk as a learning resource.

• Low · Educational Code Without Security Hardening — entire repository - basic_content/ and related directories. This repository is an educational C++ learning resource (CPlusPlusThings). Educational codebases typically contain simplified examples that may not follow production security practices. Code examples may include unsafe patterns (e.g., unsafe string handling, missing input validation) for pedagogical purposes rather than security. Fix: This is expected for educational materials. Users should be warned not to use code patterns from educational repositories directly in production. Add prominent security disclaimers to README.md
• Low · Potential Buffer Overflow in C Examples — basic_content/assert/assert.c, basic_content/c_poly/c_examp.c, basic_content/extern/. The repository contains C code examples (e.g., basic_content/assert/assert.c, basic_content/extern/extern_c++/add.c) which may demonstrate unsafe string or buffer handling patterns common in C teaching materials. Fix: If code is used as reference: validate buffer sizes, use safe string functions (strncpy instead of strcpy), and consider using C++ alternatives with bounds checking
• Low · Missing .gitignore Security Coverage — .gitignore. While a .gitignore file exists, without reviewing its contents, it's unclear if it properly excludes sensitive build artifacts, compiled binaries, IDE metadata, and other potential security-sensitive files. Fix: Ensure .gitignore includes: *.o, *.a, *.so, .out, build/, dist/, .env, .vscode/, IDE-specific files, and compiler outputs

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.