# Reading CPlusPlusThings as notes, not linking it as a library

> CPlusPlusThings is a Chinese-language C++ study repository of written explainers, a ten-day exercise sequence and bilibili source-reading episodes, aimed at beginners and interview candidates. Its one copy-paste command is a Docker pull, and it ships no releases and no named license.

**Light-City/CPlusPlusThings** — GitHub describes it as C++那些事. The repository metadata lists C++ as its primary language. This article stays within the project description and details documented in the GitHub repository README.

- Repository: https://github.com/Light-City/CPlusPlusThings
- Website: https://light-city.github.io/stories_things/
- Stars: 43,502 · Forks: 8,795
- Language: C++
- License: not declared
- Published: 2026-08-13 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/light-city-cplusplusthings

## One pull command is the whole install path

Three run routes sit under the running section: vscode + bazel, docker, and g++. Only the middle one is written as a command. The other two are bare headings, and the root of the repository holds a WORKSPACE file, the build definition Bazel expects, next to a .vscode/ directory, which fits an author who develops against the editor route rather than against a documented script.

The docker route is offered as the way to skip installing a development environment. Pull the image and read the sources from inside it:

```bash
docker pull xingfranics/cplusplusthings:latest
```

That single line is the entire install instruction on offer, and no run command follows it. The tag is `latest`, no platform list is given, and the repository publishes no GitHub releases, so nothing here pins the compiler version, the standard library, or the image contents. A reader who pulls this image later cannot tell from the project which g++ is inside it, and no version check inside the container is documented, so there is no stated way to confirm the toolchain the example sources were written against. The honest summary is that the docker image removes the setup step and replaces it with an unpinned dependency.

## Fifteen directories at the root, none of them a package

The root holds fifteen directories and four files: basic_content/, codingStyleIdioms/, concurrency/, cpp2.0/, design_pattern/, effective_cpp/, english/, extension/, img/, learn_class/, practical_exercises/, proj/, src_analysis/, tool/ and .vscode/, next to .gitignore, README.md, README_EN.md and WORKSPACE.

Read that as a filing cabinet, not a program. Each directory is a note tree with its own subtopics, and not one of them is a package: there is no install target, no exported header, and no namespace a project could depend on. WORKSPACE is a Bazel build file for the in-repo notes, not a distribution format. Anyone arriving with a CMakeLists.txt or a vcpkg manifest in hand will find nothing to paste into it, and the largest exercises sit one level down under proj/ rather than in the main tree.

Three directory names overpromise a little. extension/ and tool/ sound like tooling for other projects, when tool/ is really a reading list of debugging aids, and img/ is assets for the notes. The naming makes a fast map, but a directory that says extension/ and contains prose will send a reader looking for a plugin API that does not exist.

## basic_content files the scope operator under maohao

basic_content/ holds 25 entries, each one a single keyword or a single narrow question: const, static, this, inline, sizeof, volatile, assert, extern, struct, union, enum, decltype, using, friend, explicit, and the rest. Titles follow one 那些事 pattern throughout, which makes the folder easy to scan and just as easy to skim past.

Filenames do not always match the topic. The 那些事 entry for the scope resolution operator lives in basic_content/maohao, the pinyin for the character 号, so a reader hunting the tree for a path hinting at colons finds nothing. The same listing mixes language mechanics with C interoperability, placing c 实现 c++ 多态那些事 next to 函数指针那些事, and struct appears twice, once alone and once as struct 与 class.

Nothing in that tree is stamped against a language standard. New-feature material lives separately under cpp2.0/, split by C++11, C++14/17 and C++20, so a reader who wants to know which explainer assumes C++11 and which assumes C++14 has to open each file and look. The root listing states no compiler standard, no warning flags, and no per-file build instruction for any of them.

## Ten days in order, then fifteen single-file programs

practical_exercises/ splits into a ten-day sequence and 15 self-contained .cpp files under key_exercises/.

The ten days run in a fixed order: day1-基本语法, day2-递归、结构体、枚举、静态变量等, functions on days 3 and 4, inheritance and polymorphism on day 5, virtual functions and abstract classes on day 6, operator overloading on day 7, templates and STL on day 8, exceptions on day 9, files and streams on day 10. Day 7 through day 9 is where the density sits, and it lines up with the key_exercises/ files, which concentrate on the same ground: bracket_overloading.cpp, clock.cpp, operator_cast.cpp, operator_circle.cpp, io_operator_overload.cpp, array_template.cpp, stack.cpp, try.cpp and read_file.cpp.

Those 15 files are the friendliest thing here to compile yourself, since each stands alone with no shared header to hunt for. The catch is that no g++ line is given for them anywhere, so the only buildable artifact the project states a command for remains the docker image. The Bazel route has to be reconstructed by the reader from the WORKSPACE file, and what a given example needs on the command line is left to that reader.

## Concurrency arrives as eight video links, none of them greppable

Concurrency is the one subject handed over as video rather than as text. Eight bilibili episodes are listed, the first two covering how to build the project and how to use the docker environment, and the remaining six walking source code: HashTable, then enable_shared_from_this, the move from C++11 thread to C++20 jthread, condition_variable together with condition_variable_any, Mutex, and RAII Lock.

That choice costs you something specific. A reader searching the repository for a mutex example finds written text, but a reader searching for the reasoning behind RAII Lock finds only a link to a video page. No transcript and no chapter list is provided, and no markdown file is listed under concurrency/ in the root entries, so the written explanation of why RAII locking matters does not exist in the repository at all. Anyone who needs an offline reference they can search cannot build one out of these episodes.

The interview material has the same shape. Two Feishu documents are linked as 互联网大厂面试实录 and 拿下offer之必备面经, and both sit on a third-party wiki rather than in git, so they cannot be cloned, diffed, or searched offline alongside the code. The concurrency/ directory exists at the root, but what it contains is not described in the visible text.

## rr carries the only platform constraint the project states

tool/ collects helpers rather than a toolchain. The listed entries run from a quick output helper for containers, through a Jupyter Notebook setup that prints output the way Python does and a section on watching how the compilation process changes, to dbg-macro and rr, which is filed under a heading naming Linux and describing the ability to go back in time.

That rr entry is the only place in the project where a platform constraint is written into a heading. No macOS or Windows equivalent is named, so a reader on either of those is left with dbg-macro and nothing that rewinds execution. The distinction matters if you intend to use the examples as debugging drills rather than as reading, since replaying a fault is the entire point of the tool.

Both tools are named rather than vendored, and no install line appears for either one. Finding upstream versions is on you, as is matching them to the compiler the rest of the examples expect, and the project states no such version. The same applies to the listed course, 极客时间《现代 C++ 实战 30 讲》, which sits outside the repository entirely and brings its own access arrangement that the README does not describe.

## It is not a C++ Primer exercise answer set

If you arrived searching for C++ Primer exercise solutions, this is the wrong repository. Nothing in the root entries corresponds to a book's exercise list, and the ten-day sequence is an original curriculum rather than a chapter-by-chapter answer set. The difference in approach shows up the moment you want to check your work: a book's answer set hands you a fixed expected output to compare against, while these notes hand you a mechanism explained in prose plus a program whose output you have to reason out yourself. Useful for understanding, poor for verification.

The other place readers go is the standard library source, which people also search under Libstdc ++ source code github when an episode names an implementation detail. Here the library source is the ground truth and the notes are one reader's interpretation of it, with the six source-reading episodes acting as the bridge. No commit references to a library version appear anywhere in the notes, so a behaviour that changed in a later standard is written with exactly the same authority as one that did not. That is the boundary to keep in mind when you carry a claim from these pages into working code.

## No releases, master branch, last push on 2026-05-16

The repository is not archived, and the last push was on 2026-05-16. There are no GitHub releases, which leaves no version to pin, no changelog to read, and no upgrade path. Everything arrives as a commit on master, the default branch, and master is not a release branch here.

Licensing is the detail to settle before you copy anything. The badge row at the top of the readme file links to a LICENSE file in the repository root, but no license name appears anywhere in the visible text and the project record identifies none either. For a repository whose value is code you read and lift, that is the wrong gap to leave open: read LICENSE before you paste a file from basic_content/ or practical_exercises/ into a product, and treat the course and the video episodes as separately governed, since the repository says nothing about reusing those.

Revision tracking is the second gap. Chinese notes, a bilingual README pair at the root, and a curriculum with no version markers mean that when a page is corrected you cannot tell which correction you are reading, only that the file hash changed. Diffing two checkouts is the only way to find out what moved.

## Conclusion

Use CPlusPlusThings as a reading path if you read Chinese, are moving from basic syntax toward STL internals and threading, and want a written explanation next to a short .cpp file you can compile yourself. Skip it if you need a library to link, a versioned release, a build for macOS, or written concurrency reference material. Verify three things before you commit an hour to it: that docker pull xingfranics/cplusplusthings:latest still returns a usable image on your architecture, what the LICENSE file at the repository root actually grants, and whether the day 8 and day 9 exercises compile under the standard your own project uses, since the root listing states no compiler standard for any file.

## FAQ

### Does CPlusPlusThings ship a C++ compiler, or do I install one myself?

You supply the toolchain unless you take the docker route. Three ways to run the project are listed, vscode + bazel, docker, and g++, and only the docker one is written as a command.

### Can I run the CPlusPlusThings examples on macOS or Windows?

The docker image is described as the way to avoid setting up a development environment, and the pull line is the only command given. Among the debugging tools, rr is filed under a heading that names Linux specifically, and no equivalent is listed for macOS or Windows.

### Is the code in CPlusPlusThings licensed for me to reuse?

The badge row links to a LICENSE file in the repository root, but no license name appears in the visible text. Read that file before copying code out of basic_content/ or practical_exercises/.

## Sources

- [Official documentation](https://light-city.github.io/stories_things/)
- [Official README](https://github.com/Light-City/CPlusPlusThings#readme)
- [Project repository](https://github.com/Light-City/CPlusPlusThings)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/light-city-cplusplusthings