cpp-ipc: shared memory message passing without the ceremony

Two primitives, one data structure

The feature list is short enough to read in one pass, and each item is a design decision rather than a capability. Compilers with C++17 support are recommended, specifically msvc-2017, gcc-7 or clang-4. There are no other dependencies except the standard library. Only lock-free or lightweight spin-lock is used. A circular array is the underlying data structure.

The two primitives are `ipc::route` and `ipc::channel`. A route supports single write and multiple read. A channel supports multiple read and write, with the important caveat written into the README itself: currently a channel supports up to 32 receivers, but there is no such limit for the sender.

That asymmetry is the sort of detail that only surfaces in production, so it is good that it is stated rather than discovered. One publisher can fan out to unlimited subscribers, but a channel with more than 32 participants is not supported today.

Broadcasting is the default behaviour, and the user can choose any read and write combination instead. So if you need unicast semantics rather than fan-out, the library lets you select that rather than forcing the broadcast model on you.

No indefinite busy waiting, and why that matters

One bullet deserves to be read twice: no long time blind wait, with a semaphore used after a certain number of retries.

A naive spinlock burns a CPU core until the other side shows up. That is fine in a microbenchmark and disastrous in production, particularly on a laptop where one process spinning at 100 percent affects thermal behaviour and battery life. Bounding the spin count and then blocking on a semaphore gets the best of both: the common case where the peer is about to arrive resolves in a few instructions without a system call, and the case where it is not does not melt the machine.

This is also why the semaphore reference in the README's own reading list points at a Microsoft Research paper on implementing condition variables with semaphores. The design is borrowed deliberately rather than reinvented, and the four references are all canonical work on lock-free structures: a Dr Dobb's article on lock-free data structures, a CodeProject piece on a lock-free circular array queue, a Chinese-language blog series on lock-free programming, and a CoolShell article on lock-free queue implementation.

Two of those four references are in Chinese, which tells you something about where the technique was learned from and is worth noting for anyone reading the design lineage.

The benchmark numbers are old, and the reader should know it

The README publishes a performance table and it is worth reading carefully rather than quoting. The device is a Lenovo ThinkPad T450, the CPU an Intel Core i5-4300U at 2.5 GHz, the RAM 16 GB, the operating system Windows 7 Ultimate x64, and the compiler MSVC 2017 15.9.4.

Those are the specifications of a 2014 laptop running an operating system Microsoft stopped supporting in January 2020. Whatever the absolute numbers were when measured, they do not describe current hardware, and they do not describe Linux at all despite that being one of the three target platforms.

The underlying data is in `performance.xlsx` at the repository root, and the unit and benchmark tests are in the `test/` directory. So the numbers are not a marketing table; they point at a spreadsheet and a test harness you can inspect. What the README provides is the environment so the spreadsheet can be interpreted.

The honest framing is that this tells you the library was measured carefully enough to publish its conditions, but that anyone needing current numbers should run the benchmark suite in `test/` on their own hardware. A library that publishes its test machine alongside its results is doing the right thing even when the test machine is old enough that the operating system is end of life.

One more file worth knowing about is `codecov.yml`, which means coverage is tracked in CI.

A small repository with a coherent structure

The tree is compact for a library with more than 2,200 stars and nearly 400 forks. There is `include/` for the public headers, `src/` for implementation, `demo/` for example usage, and `test/` for the unit and benchmark tests. `CMakeLists.txt` is the build definition and `3rdparty/` holds vendored dependencies.

That is the whole project. There is no documentation directory, no examples tree beyond `demo/`, and no wiki content in the repository itself. Instead, the README points to a wiki for usage:

The external wiki being the actual usage documentation is the important structural fact about this project. It means the repository is a library plus tests, and the teaching material lives elsewhere. For anyone evaluating whether they can support themselves, that is a consideration: the code is small and readable, but the worked examples are not in the repository.

The topic list is precise and unglamorous: cpp, cpp17, ipc, linux, shared-memory, windows. FreeBSD appears in the description line but not in the topics, which is worth noticing if that platform matters to you, since nothing in the repository beyond that mention confirms the current state of FreeBSD support.

Licensing stated two different ways, and a maintainer joining

GitHub reports the license as NOASSERTION, meaning no standard licence identifier could be detected from the repository metadata. The README, however, carries an MIT badge at the top linking directly to the LICENSE file, and there is a LICENSE file in the tree.

Both facts are true and neither is unusual. NOASSERTION commonly happens when GitHub cannot classify a licence automatically, and MIT in a plain text file is the most conventional licence there is. A reader who wanted certainty should read the LICENSE file itself rather than relying on the metadata field, and the README badge points there.

The more interesting item is the final bullet in the feature list: Cookie (OpenClaw) is collaborating on this project. That is a maintainer disclosure rather than a feature, and it sits at the end of a list of technical properties, which suggests it was added when a second maintainer arrived. For a project with 65 open issues and a last push on 2026-03-14, having another person involved is a meaningful change in the maintenance picture.

On that date, and this is worth stating plainly: the last push was more than 180 days before the current date, so the repository is not archived but is not receiving recent commits either. There are three releases, with v1.4.1 from 2025-12-12, v1.4.0 from 2025-12-09 and v1.3.0 from 2023-10-31. That gap between 1.3.0 and 1.4.0 tells you the project spent most of two years planning a release rather than shipping continuously.

Installing through vcpkg is the shortest path

The README names installation through vcpkg and gives the exact command:

vcpkg install cpp-ipc

There is a vcpkg package badge in the header linking to the port in the Microsoft repository, which means the package is maintained in-tree rather than being an abandoned entry someone is maintaining from outside. For a C++ library with no dependencies of its own, a vcpkg port means you get the dependency resolution and ABI tracking behaviour that the rest of your C++ dependencies already rely on.

The header badges show a consistent CI story: a GitHub Actions build status for the c-cpp workflow, a CodeCov badge, and an AppVeyor build status on the master branch. Running both GitHub Actions and AppVeyor is a belt and braces setup, and AppVeyor's presence alongside GitHub Actions suggests the project has been doing continuous integration on Windows long enough that the older service was still the natural choice.

The practical recommendation follows from the design rather than the tooling. This library is for processes on one machine exchanging fixed size messages where latency matters and you control both ends. It is not a replacement for gRPC or a message broker, and the absence of any network transport in the feature list makes that boundary unambiguous. If your processes run on different hosts, shared memory is the wrong mechanism and this is the wrong library.

Editorial conclusion

cpp-ipc is a focused library that solves one problem: getting fixed size messages between processes on the same machine faster than a socket would. It does that with two primitives, a lock-free circular array, and no dependencies beyond the standard library, and it ships through vcpkg so adoption is a one line change. The trade is explicit in the README itself: a channel currently supports up to 32 receivers, there is no such limit for the sender, and the library is built for same-machine shared memory rather than networked transport. Reach for it when you control both ends and the message shape is fixed, and read the performance spreadsheet before trusting any of the published numbers, because they were measured on a 2014 laptop under Windows 7.

Frequently asked questions

Official sources

1. Issues
2. mutouyun/cpp-ipc on GitHub
3. README
4. Releases