-
Stay up-to-date with everything C++! Content directly fetched from the subreddit just for you. Join our group for discussions : @programminginc Powered by : @r_channels
Any fun c++ projects i can make in 1-2 weeks
I’m not interested in overly complex projects that take months. I’m looking for something fun and unique that, once seen, would make people say, “That’s something new.”
I can integrate python or rust based things also in it if required or something related to agentic system
Thanks in advance.
https://redd.it/1qzca23
@r_cpp
Implementing vector<T>
https://accu.org/journals/overload/34/191/chunawala/
https://redd.it/1qz4nhm
@r_cpp
"override members" idea as a gateway to UFCS (language evolution)
(UFCS backgrounder: https://isocpp.org/files/papers/N4174.pdf )
I have two functions that tell me if a string contains the
characters of a particular integer. They're called hasInt and intIn.
(intIn is inspired by the python keyword in.)
They looks like this:
bool hasInt(const string s, int n)// does s have n?
{
return s.contains(tostring(n));
}
bool intIn(int n, const string s)// is n in s?
{
return s.contains(tostring(n));
}
It would be convenient if I could add hasInt as a member function to std::string:
bool string::hasInt(int n)
{
return ::hasInt(this, n);
}
Then I could use "member syntax" to call the function, like `text.hasInt(123)`.
Of course, that's not possible, because then I'd be changing the header files
in the standard libraries.
Here's an idea for a new language feature:
let's use the `override` keyword to allow us to "inject" member functions
into an existing class, without modifying the class definition. So the code:
override bool string::hasInt(int n)
{
return ::hasInt(this, n);
}
will (in effect) add hasInt as a member function to string.
Thus, this "override member function" feature has a syntax like:
ReturnType ClassName::function(args){...etc...}
HOWEVER..... what if ClassName doesn't necessarily need to be a class, and could be
other types? Then you open the door to override members like:
override bool int::intIn(const string s)
{
return ::intIn(this, s);
}
Which allows code like `(123).intIn(text)`.
This is halfway to UFCS!
Using some macro magic and helper templates, we could define a
MAKE_UFCS macro to convert a non-member function into a member function:
#define MAKE_UFCS(f) \
override \
retType(f) argType1(f)::f(argType2(f) x)\
{ \
return f(this, x); \
}
Thus the non-member functions hasInt and intIn could be "opted in" to UFCS
by the macro calls:
MAKEUFCS(hasInt);
MAKEUFCS(intIn);
Or maybe, if this override-to-UFCS is useful enough, the override feature can be
applied to a collection of functions at once, like:
override hasInt, intIn;
or
override {
#include <cstdlib>
}
To UFCS-ify an entire header file at the same time.
EDIT: this idea would be similar to Scala's "Extension Methods": https://docs.scala-lang.org/scala3/book/ca-extension-methods.html
or C#'s "Extension Members": https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/extension-methods
https://redd.it/1qyikcg
@r_cpp
WCout - a C++ utility that simplifies data formatting and display. It uses only '<<' to format, add and display data
https://github.com/pinardmichel14-sudo/WCoutSrc
https://redd.it/1qy4jf1
@r_cpp
25+ years of pathfinding problems with C++ - Raymi Klingers - Meeting C++ 2025
https://www.youtube.com/watch?v=lEBQveBCtKY
https://redd.it/1qxo72w
@r_cpp
Mathieu Ropert: Learning Graphics Programming with C++
https://youtu.be/vL87j4wup1U
https://redd.it/1qxeohs
@r_cpp
SimpleBLE v0.11.0 - Introducing Peripheral Mode for Linux
Hey everybody, SimpleBLE v0.11.0 is finally live! We focused on making the most versatile Bluetooth library even more useful.
For those who don’t know, SimpleBLE is a cross-platform Bluetooth library with a very simple API that just works, allowing developers to easily integrate it into their projects without much effort, instead of wasting hours and hours on development.
This release mainly focuses on a single big feature for Linux that has been a year in the making: BLE Peripheral support.
This means your Linux machine can now:
• Advertise as a BLE device
• Expose GATT services and characteristics
• Act as a complete peripheral
Why does this matter?
If you thought using Central roles with the native Bluetooth stacks was hard, Peripheral takes this to a whole new level. It took us a very long time to find the right data representations that could abstract this problem away cleanly, but we’ve finally reached a point we feel comfortable sharing with a wider audience.
This barrier is now gone, and with it a whole new world of possibilities opens up: Building custom peripheral applications, device emulators or hardware mocks, all without any extra hardware. I’m excited to see what new ideas come to life based on this new capability.
You can find our Peripheral-specific examples here and here. Things might still break or change as we improve it and work towards a generalized API for all other OSes, but should be good enough to start validating ideas. We’d love to hear about your experience!
Want to know more about SimpleBLE's capabilities or see what others are building with it? Ask away!
https://redd.it/1qxbvyi
@r_cpp
P1689's current status is blocking module adoption and implementation - how should this work?
There is a significant "clash of philosophies" regarding Header Units in the standard proposal for module dependency scanning P1689 (it's not standard yet because it doesn't belong to the language standard and the whole ecosystem is thrown to trash by now but it's de facto) that seems to be a major blocker for universal tooling support.
# The Problem
When scanning a file that uses header units, how should the dependency graph be constructed? Consider this scenario:
// a.hh
import "b.hh";
// b.hh
// (whatever)
// c.cc
import "a.hh";
When we scan c.cc, what should the scanner output?
Option 1: The "Module" Model (Opaque/Non-transitive) The scanner reports that c.cc requires a.hh. It stops there. The build system is then responsible for scanning a.hh separately to discover it needs b.hh.
Rationale: This treats a header unit exactly like a named module. It keeps the build DAG clean and follows the logic that `import` is an encapsulated dependency.
Option 2: The "Header" Model (Transitive/Include-like) The scanner resolves the whole tree and reports that `c.cc` requires both `a.hh` and `b.hh`.
Rationale: Header units are still headers. They can export macros and preprocessor state. Importing a.hh is semantically similar to including it, so the scanner should resolve everything as early as possible (most likely using traditional -I paths), or the impact on the importing translation unit is not clear.
# Current Implementation Chaos
Right now, the "Big Three" are all over the place, making it impossible to write a universal build rule:
1. Clang (clang-scan-deps): Currently lacks support for header unit scanning.
2. GCC (-M -Mmodules): It essentially deadlocks. It aborts if the Compiled Module Interface (CMI) of the imported header unit isn't already there. But we are scanning specifically to find out what we need to build!
3. MSVC: Follows Option 2. It resolves and reports every level of header units using traditional include-style lookup and aborts if the physical header files cannot be found.
# The Two Core Questions
1. What is the scanning strategy? Should import "a.hh" be an opaque entry as it is in the DAG, or should the scanner be forced to look through it to find b.hh?
2. Looking-up-wise, is import "header" a fancy #include or a module?
If it's a fancy include: Compilers should use `-I` (include paths) to resolve them during the scan. Then we think of other ways to consume their CMIs during the compilation.
If it's a module: They should be found via module-mapping mechanics (like MSVC's /reference or GCC's module mapper).
# Why this matters
We can't have a universal dependency scanning format (P1689) if every compiler requires a different set of filesystem preconditions to successfully scan a file, or if each of them has their own philosophy for scanning things.
If you are a build system maintainer or a compiler dev, how do you see this being resolved? Should header units be forced into the "Module" mold for the sake of implementation clarity, or must we accept that they are "Legacy+" and require full textual resolution?
I'd love to hear some thoughts before this (hopefully) gets addressed in a future revision of the proposal.
https://redd.it/1qx7zex
@r_cpp
C++ Podcasts & Conference Talks (week 6, 2025)
Hi r/cpp! Welcome to another post in this series. Below, you'll find all the C++ conference talks and podcasts published in the last 7 days.
Before we start, apologies for the last week where my compilation included talks irrelevant to C++. I'll make sure to do my due diligence before posting here.
# 📺 Conference talks
# CppCon 2025
1. **"Compiler Explorer: The Features You Never Knew Existed - Matt Godbolt - CppCon 2025"** ⸱ +11k views ⸱ 30 Jan 2026 ⸱ 01h 00m 08s
2. **"Networks in C++ - What's Actually Changing? - Ignas Bagdonas - CppCon 2025"** ⸱ +4k views ⸱ 29 Jan 2026 ⸱ 01h 12m 42s
3. **"Mastering the Code Review Process - Pete Muldoon - CppCon 2025"** ⸱ +3k views ⸱ 28 Jan 2026 ⸱ 01h 08m 34s
4. **"Connecting C++ Tools to AI Agents Using the Model Context Protocol (MCP) - Ben McMorran - CppCon"** ⸱ +1k views ⸱ 02 Feb 2026 ⸱ 00h 29m 32s
5. **"The Truth About Being a Programmer CEO - Greg Law - CppCon 2025"** ⸱ +600 views ⸱ 03 Feb 2026 ⸱ 01h 24m 02s
# Meeting C++ 2025
1. **"Speed for Free - current state of auto vectorizing compilers - Stefan Fuhrmann - Meeting C++ 2025"** ⸱ +700 views ⸱ 31 Jan 2026 ⸱ 00h 42m 02s
This post is an excerpt from the latest issue of ***Tech Talks Weekly*** which is a free weekly email with all the recently published Software Engineering and Development conference talks & podcasts. Currently subscribed by +8,200 Software Engineers who stopped scrolling through messy YouTube subscriptions and reduced FOMO. Consider subscribing if this sounds useful: *https://www.techtalksweekly.io/*
Let me know what you think. Thank you!
https://redd.it/1qwp1a8
@r_cpp
Feedback wanted: C++20 tensor library with NumPy-inspired API
I've been working on a tensor library and would appreciate feedback from people who actually know C++ well.
**What it is:** A tensor library targeting the NumPy/PyTorch mental model - shape broadcasting, views via strides, operator overloading, etc.
**Technical choices I made:**
* C++20 (concepts, ranges where appropriate)
* xsimd for portable SIMD across architectures
* Variant-based dtype system instead of templates everywhere
* Copy-on-write with shared\_ptr storage
**Things I'm uncertain about:**
* Is the Operation registry pattern overkill? It dispatches by OpType enum + Device
* Using std::variant for axis elements in einops parsing - should this be inheritance?
* The BLAS backend abstraction feels clunky
* Does Axiom actually seem useful?
* What features might make you use it over something like Eigen?
It started because I wanted NumPy's API but needed to deploy on edge devices without Python. Ended up going deeper than expected (28k LOC+) into BLAS backends, memory views, and GPU kernels.
Github: [https://github.com/frikallo/axiom](https://github.com/frikallo/axiom)
Would so appreciate feedback from anyone interested! Happy to answer questions about the implementation.
https://redd.it/1qu3acu
@r_cpp
Flavours of Reflection
https://semantics.bernardteo.me/2026/01/30/flavours-of-reflection.html
https://redd.it/1qtzsxa
@r_cpp
C++ & CUDA reimplementation of StreamDiffusion
https://github.com/jcelerier/librediffusion
https://redd.it/1qvbv1j
@r_cpp
capabilities. This is an area of active development, but I plan to release a working prototype soon.
https://redd.it/1quxak5
@r_cpp
([docs](https://www.fleetcode.com/oss/tmc/docs/v1.4/executors/ex_cpu.html#hybrid-work-steering))([example](https://github.com/tzcnt/tmc-examples/blob/44ce66de8e74107c803645c82ddd88a7be35fd29/examples/hwloc/hybrid_executor.cpp)) Implement work steering for P- and E- cores on hybrid chips (e.g. Intel Hybrid / ARM big.LITTLE). Apple M / MacOS is also supported by setting the QoS class.
* ([example](https://github.com/tzcnt/tmc-examples/blob/44ce66de8e74107c803645c82ddd88a7be35fd29/examples/hwloc/asio_thread_per_core.cpp)) Turn Asio into a thread-per-core, share-nothing executor
* ([example](https://github.com/tzcnt/tmc-examples/blob/44ce66de8e74107c803645c82ddd88a7be35fd29/examples/hwloc/asio_server_per_cache.cpp)) Create an Asio thread *and* a worker thread pool for each chiplet in the system, that communicate exclusively within the same cache. This lets you scale both I/O and compute without cross-cache latency.
# Killer Features, Round 2
TooManyCooks offers several other features that others do not:
* ([docs](https://fleetcode.com/oss/tmc/docs/v1.4/halo/index.html)) ([example](https://github.com/tzcnt/tmc-examples/blob/44ce66de8e74107c803645c82ddd88a7be35fd29/tests/test_halo.cpp)) support for the only working HALO implementation ([Clang attributes](https://clang.llvm.org/docs/AttributeReference.html#coro-await-elidable))
* ([docs](https://www.fleetcode.com/oss/tmc/docs/v1.4/type_traits.html)) type traits to let you write generic code that handles values, awaitables, tasks, and functors
* ([docs](https://www.fleetcode.com/oss/tmc/docs/v1.4/priority.html)) support for multiple priority levels, as well as executor and priority affinity, are integrated throughout the library
* ([example](https://github.com/tzcnt/tmc-examples/blob/44ce66de8e74107c803645c82ddd88a7be35fd29/examples/asio/http_server.cpp)) seamless Asio integration
# Mundane Feature Parity
TooManyCooks also aims to offer feature parity with the usual things that other libraries do:
* ([docs](https://www.fleetcode.com/oss/tmc/docs/v1.4/executors/index.html)) various executor types
* ([docs](https://www.fleetcode.com/oss/tmc/docs/v1.4/awaitables/index.html)) various ways to fork/join tasks
* ([docs](https://www.fleetcode.com/oss/tmc/docs/v1.4/data_structures/channel.html)) async data structures (tmc::channel)
* ([docs](https://www.fleetcode.com/oss/tmc/docs/v1.4/control_structures/index.html)) async control structures (tmc::mutex, tmc::semaphore, etc)
# Designed for Brownfield Development
TooManyCooks has a number of features that will allow you to slowly introduce coroutines/task-based concurrency into an existing codebase without needing a full rewrite:
* ([docs](https://fleetcode.com/oss/tmc/docs/v1.4/awaitables/fork_group.html)) flexible awaitables like `tmc::fork_group` allow you to limit the virality of coroutines - only the outermost (awaiting) and innermost (parallel/async) function actually need to be coroutines. Everything in the middle of the stack can stay as a regular function.
* global executor handles (`tmc::cpu_executor()`, `tmc::asio_executor()`) and the `tmc::set_default_executor()` function let you initiate work from anywhere in your codebase
* ([docs](https://fleetcode.com/oss/tmc/docs/v1.4/executors/ex_manual_st.html)) a manual executor lets you run work from inside of another event loop at a specific time
* ([docs](https://fleetcode.com/oss/tmc/docs/v1.4/integration/external_awaitables.html#default-behavior-it-just-works)) ([example](https://github.com/tzcnt/tmc-examples/blob/44ce66de8e74107c803645c82ddd88a7be35fd29/examples/external/external_awaitable.cpp)) foreign awaitables are automatically wrapped to maintain executor and priority affinity
* ([docs](https://fleetcode.com/oss/tmc/docs/v1.4/integration/external_awaitables.html#fully-integrating)) ([example](https://github.com/tzcnt/tmc-examples/blob/44ce66de8e74107c803645c82ddd88a7be35fd29/examples/external/callback_awaitable.hpp#L157)) or you can specialize `tmc::detail::awaitable_traits` to fully integrate an external awaitable
*
C++ Show and Tell - February 2026
Use this thread to share anything you've written in C++. This includes:
* a tool you've written
* a game you've been working on
* your first non-trivial C++ program
The rules of this thread are very straight forward:
* The project must involve C++ in some way.
* It must be something you (alone or with others) have done.
* Please share a link, if applicable.
* Please post images, if applicable.
If you're working on a C++ library, you can also share new releases or major updates in a dedicated post as before. The line we're drawing is between "written in C++" and "useful for C++ programmers specifically". If you're writing a C++ library or tool for C++ developers, that's something C++ programmers can use and is on-topic for a main submission. It's different if you're just using C++ to implement a generic program that isn't specifically about C++: you're free to share it here, but it wouldn't quite fit as a standalone post.
Last month's thread: https://www.reddit.com/r/cpp/comments/1q3m9n1/c_show_and_tell_january_2026/
https://redd.it/1qvkkfn
@r_cpp
I think build systems shouldn't have variables that affect flags
Having cmake, meson etc parse your flags and options is more cumbersome than it worth, and is usually a source of bugs.
I think the correct approach for any new toolchain should be to have a separate toolchain file for everything you want to do. A toockhain file should only define binaries and flags.
want to have lto? use the toolchain with -flto
want to have PIC? use the toolchain that has -fPIC
Having cmake take a variable like -DINTERPROCEDURAL_OPTIMIZATION to have a lot build with the same toolchain just leads to bugs. Often some projects simply ignore your flags anyway
Also, flags change as compiler version changes. So you have to constantly maintain the build system.
\----
I'm honestly tired of projects ignoring my flags, for example llvm compiler RT ignoring add_linkoptions, or cmke ignoring add_compile_options for building std module. I had to use old cxx init variables.
I think this was a bad idea from the beginning, A modern build system should just have a nice DSL, and take flags and executables and that's it. It shouldn't deal with other build systems, it shouldn't act as a package manager.
It should be a binary, not a python package so the scripting should be built in.
Anyway, this was my rant/discussion or whatever.
https://redd.it/1qz55an
@r_cpp
microsoft/proxy Polymorphism Library is no longer actively maintained under the Microsoft organization
After 6 months of announcing new version of this lib, today I found that it's been archived and transferred from Microsoft organization to a new established organization ngcpp two weeks ago.
I haven’t been keeping up with the latest cpp news recently, but since the rumor about Microsoft towards C++ last year, I hope this doesn't mean anything bad.
https://redd.it/1qz3lhf
@r_cpp
Fintech C++ vs C developer in networking
Hey folks 👋
Looking for some grounded, real-world opinions from people who’ve actually worked in these domains.
I’m currently an embedded/systems developer working with C, Linux, networking, and Wi-Fi. I’m at a crossroads between two very different domains and trying to figure out which one offers the best learning curve and long-term stability.
I currently have three possible tracks:
1) Ofcourse, Broadband / Networking
C + Linux + Wi-Fi (6/7), mesh, gateways, ISP stacks — RDK-B, networking protocols, device software.
2) Finance / Wealth Management C++
C++ application development — banking/wealth systems, equity & MF flows. Although i am not sure about the excat work. They require c++ for wealth management software.
- As a Broadband Engineer i can work closely with WiFi 7, 6G, and Mesh technologies.
- And I'm not so aware about the opening for C++ Devs in this area.
My main question:
1) Over a 10–15 year horizon, which path offers: Better learning depth, Career stability, Flexibility to move roles or domains.
If you had to pick one domain for 2026 and beyond, which would it be and why?
Not looking for a “this pays more” answer. More interested in signal vs noise, saturation vs skill, and long-term optionality.
Would love to hear from people actually working in these areas 🙏
https://redd.it/1qymtpz
@r_cpp
Parallel Range Algorithms: The Evolution of Parallelism in C++ Ruslan Arutyunyan - CppCon 2025
https://www.youtube.com/watch?v=LVDr0132vUI
https://redd.it/1qxpx33
@r_cpp
Parallel C++ for Scientific Applications: Tasks & Concurrency (1st Part)
https://www.youtube.com/watch?v=_U80M3XY7hU
https://redd.it/1qxmfwv
@r_cpp
cppfront
I don't think https://github.com/hsutter/cppfront gets much attention. What do people think of it?
It solves so much of the mess in C++. As far as I can see, only threading still needs to be solved to be comparable to Rust?
Maybe that could be solved by a method similar to Google's thread annotation, just built-in instead of macros?
https://redd.it/1qxc1ns
@r_cpp
Try this Quiz! https://cppquiz.org/quiz/question/1
CppQuiz.org - Question #1
Comment your score below
https://redd.it/1qx997s
@r_cpp
A little clarity on FP needed
My intention is not to start a OO vs FP argument. I honestly feel like my experience has a void in it and I need to improve my understanding of some things.
I am traditionally OO and any time FP comes up and people debate the two, I usually only hear about deep inheritance trees as the sole premise. That was never enough to convince me to throw out all the bath water with the baby. In my mind, I can be OO, do SOLID, use RAII, and never inherit more than 1 interface, if I want to.
Failing to get any reasonable explanation from my peers, I started doing some research and I finally came across something that started to make sense to me.
The response was: "FP is becoming more popular because of distributed systems and how CPUs can no longer get faster, but add more cores. Therefore, we are doing a lot more where concurrency matters. In FP there is an idealogy to deal with 'pure functions' that act on immutable data, and create new data or events instead of mutate state within classes."
Well, that sounds good to me. So, I wanted to explore some examples. Person/Order, User/Logins, etc. I noticed in the examples, collections like a vector would be passed as a parameter by value and then a new vector would be returned.
Now, I admittedly don't know FP from my foot, but I'd like to understand it.
Is immutability carried to that extreme? Copying a big collection of data is expensive, after all.
I then got debate on how move semantics help, but couldn't get any examples to look at that did not have a copy, since after all, we are trying to deal with immutable data.
Is this legit FP?
struct Item {
ProductId productId;
int quantity;
};
struct Order {
OrderId id;
std::vector<Item> items;
};
Order addItemToOrder(const Order& order, Item item) {
Order newOrder = order;
newOrder.items.pushback(item);
return newOrder;
}
or would you
Order addItemToOrder(const Order& order, Item item) {
Order newOrder;
newOrder.id = order.id;
newOrder.items = order.items;
newOrder.items.pushback(item);
return newOrder;
}
Both of these seem to have a copy of the vector, and I'd imagine that would be a lot of performance cost for an idealogy, no?
I then got a response where they said to use a shared_ptr for the items in the order and add to it as needed, but then we are mutating a struct, so what's did we gain from using a class with methods to add items to an order object?
Is the reality we just have to be smart and drop carrying a ideal of keeping things immutable when the performance cost would be large? Or do the examples stink? Could you help solidify the FP way of doing things with orders and items in a system, where the person is adding items to the order and the entire order needs to be submitted to a db when they checkout?
https://redd.it/1qx6m0o
@r_cpp
New C++ Conference Videos Released This Month - February 2026
**CppCon**
2026-01-26 - 2026-02-01
* Using Floating-point in C++: What Works, What Breaks, and Why - Egor Suvorov - [https://youtu.be/m83TjrB6wYw](https://youtu.be/m83TjrB6wYw)
* Cross-Platform Package Management for Modern C++ Development with Pixi - Ruben Arts - [https://youtu.be/SQk0lKv2swk](https://youtu.be/SQk0lKv2swk)
* Mastering the Code Review Process - Pete Muldoon - [https://youtu.be/6a3CNRMssQE](https://youtu.be/6a3CNRMssQE)
* Networks in C++ - What's Actually Changing? - Ignas Bagdonas - [https://youtu.be/dVSCMJlHXQM](https://youtu.be/dVSCMJlHXQM)
* Compiler Explorer: The Features You Never Knew Existed - Matt Godbolt - [https://youtu.be/3W0vE\_VKokY](https://youtu.be/3W0vE_VKokY)
**ADC**
2026-01-26 - 2026-02-01
* Minimalistic Music Composition with C++ - Xyzzy - ADCx Gather 2025 - [https://youtu.be/9x49IxlrkqI](https://youtu.be/9x49IxlrkqI)
* The Real Waveform Matters - The Samples Are Not Always What They Seem - Jamie Angus-Whiteoak - ADC 2025 - [https://youtu.be/8eEWK6Fez8c](https://youtu.be/8eEWK6Fez8c)
**Meeting C++**
2026-01-26 - 2026-02-01
* Purging undefined behavior and Intel assumptions in Legacy Codebases - Roth Michaels - [https://www.youtube.com/watch?v=b7SZdhrEsic](https://www.youtube.com/watch?v=b7SZdhrEsic)
* 25+ years of pathfinding problems with C++ - Raymi Klingers - [https://www.youtube.com/watch?v=lEBQveBCtKY](https://www.youtube.com/watch?v=lEBQveBCtKY)
* Speed for Free - current state of auto vectorizing compilers - Stefan Fuhrmann - [https://www.youtube.com/watch?v=m2vVWkFsrM0](https://www.youtube.com/watch?v=m2vVWkFsrM0)
**ACCU Conference**
2026-01-26 - 2026-02-01
* The Beman Project: Testing C++ Library Proposals Before Standardization - Dietmar Kühl - ACCU 2025 Short Talks - [https://youtu.be/wXQE\_Upqbms](https://youtu.be/wXQE_Upqbms)
* A Sixth Seam in TDD? - Python Testing, Test Doubles & Legacy Code at Kosli - Jon Jagger - ACCU 2025 Short Talks - [https://youtu.be/62EltmSbqro](https://youtu.be/62EltmSbqro)
* What, What? - When We Think We Understand - Nara Morrison - ACCU 2025 Short Talks - [https://youtu.be/W0vAsaL\_svY](https://youtu.be/W0vAsaL_svY)
https://redd.it/1qtznyb
@r_cpp
Silent foe or quiet ally: Brief guide to alignment in C++. Part 2
https://pvs-studio.com/en/blog/posts/cpp/1340/
https://redd.it/1qul1u6
@r_cpp
A Faster WBT/SBT Implementation Than Linux RBT
https://typecombinator.github.io/en/posts/top\_down\_weight\_balanced\_tree
https://redd.it/1qunnpw
@r_cpp
Claude Code MCP server mcp-cpp-server broken after Claude Code 2.1.28+ update
Hey everyone,
If you use **mcp-cpp-server** (the Rust-based MCP server for C++ code analysis via clangd) with **Claude Code**, it silently breaks after updating Claude Code to 2.1.28+.
`claude mcp list` shows the server as "Failed to connect" with no useful error. After digging through stderr logs, the actual error is:
```
Incompatible protocol version: client: 2025-11-25 server: 2025-06-18
```
**What happened:** Claude Code 2.1.28 switched to MCP protocol version `2025-11-25`, but `mcp-cpp-server` v0.2.2 uses `rust-mcp-sdk` 0.7.4 which only speaks protocol `2025-06-18`. The server starts fine but Claude rejects the handshake.
**The fix:** Upgrade `rust-mcp-sdk` from 0.7 to 0.8 in Cargo.toml, plus a few API changes the new SDK requires:
\- `Implementation` struct needs new fields (`description`, `icons`, `website_url`)
\- `create_server()` now takes a `McpServerOptions` struct instead of positional args
\- `handle_list_tools_request` / `handle_call_tool_request` signatures changed
\- Handler conversion uses `.to_mcp_server_handler()` now
I've submitted **PR #12** upstream: https://github.com/mpsm/mcp-cpp/pull/12
**To use it now** (before the PR merges):
```bash
git clone https://github.com/ninokth/mcp-cpp.git
cd mcp-cpp
git checkout fix/sdk-0.8-upgrade
cargo build --release
cp target/release/mcp-cpp-server \~/.cargo/bin/
```
After that, `claude mcp list` should show `cpp: Connected` and all three tools (`search_symbols`, `analyze_symbol_context`, `get_project_details`) work again.
Hope this helps anyone else who hit this wall.
https://redd.it/1qwg9zy
@r_cpp
([docs](https://fleetcode.com/oss/tmc/docs/v1.4/integration/external_executors.html#fully-integrating)) ([example](https://github.com/tzcnt/tmc-examples/blob/44ce66de8e74107c803645c82ddd88a7be35fd29/examples/external/external_executor.cpp#L68)) specialize `tmc::detail::executor_traits` to integrate an external executor
* ([example](https://github.com/tzcnt/tmc-examples/blob/44ce66de8e74107c803645c82ddd88a7be35fd29/examples/external/callback_awaitable.hpp)) you can even turn a C-style callback API into a TooManyCooks awaitable!
# Designed for Beginners and Experts Alike
TooManyCooks wants to be a library that you'll choose first because it's easy to use, but you won't regret choosing later (because it's also very powerful).
To start, it offers the simplest possible syntax for awaitable operations, and requires almost no boilerplate. To achieve this, sane defaults have been chosen for the most common behavior. However, you can also customize almost everything using fluent APIs, which let you orchestrate complex task graphs across multiple executors with ease.
TooManyCooks attempts to emulate linear types (it expects that most awaitables are awaited exactly once) via a combination of \[\[nodiscard\]\] attributes, rvalue-qualified operations, and debug asserts. This gives you as much feedback as possible at compile time to help you avoid lifetime issues and create correct programs.
There is carefully maintained [documentation](https://www.fleetcode.com/oss/tmc/docs/v1.4/quick_start.html) as well as an extensive suite of [examples and tests](https://github.com/tzcnt/tmc-examples) that offer code samples for you to draw from.
# Q&A
# Is this AI slop? Why haven't I heard of this before?
I've been building in public since 2023 and have invested thousands of man-hours into the project. AI was never used on the project prior to version 1.1. Since then I've used it mostly as a reviewer to help me identify issues. It's been a net positive to the quality of the implementation.
This announcement is well overdue. I could have just "shipped it" many months ago, but I'm a perfectionist and prefer to write code rather than advertise. This has definitely caused me to miss out on "first-mover advantage". However, at this point I'm convinced the project is world-class so I feel compelled to share.
# The name is stupid.
That's not a question, but I'll take it anyway. The name refers to the phrase "too many cooks in the kitchen", which I feel is a good metaphor for all the ways things can go wrong in a multithreaded, asynchronous system. Blocking, mutex contention, cache thrashing, and false sharing can all kill your performance, in the same way as two cooks trying to use the same knife. TooManyCooks's structured concurrency primitives and lock-free internals let you ensure that your cooks get the food out the door on time, even under dynamically changing, complex workloads.
# Will this support Sender/Receiver?
Yes, I plan to make it S/R compatible. It already supports core concepts such as [scheduler affinity](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3552r3.html#scheduler-affinity) so I expect this will not be a heavy lift.
# Are C++20 coroutines ready for prime time?
In my opinion, there were 4 major blockers to coroutine usability. TooManyCooks offers solutions for all of them:
* Compiler implementation correctness - This is largely solved.
* Library maturity - TooManyCooks aims to solve this.
* HALO - Clang's [attributes](https://clang.llvm.org/docs/AttributeReference.html#coro-await-elidable) are the only implementation that actually works. TooManyCooks fully supports this, and it applies consistently ([docs](https://fleetcode.com/oss/tmc/docs/v1.4/halo/index.html)) ([example](https://github.com/tzcnt/tmc-examples/blob/44ce66de8e74107c803645c82ddd88a7be35fd29/tests/test_halo.cpp)) when the prerequisites are met.
* Debugger integration - LLDB has recently merged support for SyntheticFrameProviders which allow reconstructing the async backtrace in the debugger. GDB also offers a Frame Filter API with similar
Announcing TooManyCooks: the C++20 coroutine framework with no compromises
[TooManyCooks](https://github.com/tzcnt/TooManyCooks) aims to be the fastest general-purpose C++20 coroutine framework, while offering unparalleled developer ergonomics and flexibility. It's suitable for a variety of applications, such as game engines, interactive desktop apps, backend services, data pipelines, and (consumer-grade) trading bots.
It competes directly with the following libraries:
* tasking libraries: libfork, oneTBB, Taskflow
* coroutine libraries: cppcoro, libcoro, concurrencpp
* asio wrappers: boost::cobalt (via [tmc-asio](https://github.com/tzcnt/tmc-asio))
# TooManyCooks is Fast (Really)
I maintain a comprehensive suite of benchmarks for competing libraries. You can view them here: ([benchmarks repo](https://github.com/tzcnt/runtime-benchmarks)) ([interactive results chart](https://fleetcode.com/runtime-benchmarks/))
TooManyCooks beats every other library (except libfork) across a wide variety of hardware. I achieved this with cache-aware work-stealing, lock-free concurrency, and many hours of obsessive optimization.
TooManyCooks also doesn't make use of any ugly performance hacks like busy spinning ([unless](https://www.fleetcode.com/oss/tmc/docs/v1.4/executors/ex_cpu.html#_CPPv4N3tmc6ex_cpu9set_spinsE6size_t) you [ask it to](https://www.fleetcode.com/oss/tmc/docs/v1.4/data_structures/channel.html#_CPPv4N3tmc8chan_tok18set_consumer_spinsE6size_t)), so it respects your laptop battery life.
# What about libfork?
I want to briefly address libfork, since it is typically the fastest library when it comes to fork/join performance. However, it is arguably not "general-purpose":
* ([link](https://github.com/ConorWilliams/libfork?tab=readme-ov-file#-welcome-to-libfork--)) it requires arcane syntax (as a necessity due to its implementation)
* it requires every coroutine to be a template, slowing compile time and creating bloat
* limited flexibility w.r.t. task lifetimes
* no I/O, and no other features
Most of its performance advantage comes from its custom allocator. The recursive nature of the benchmarks prevents HALO from happening, but in typical applications (if you use Clang) HALO will kick in and prevent these allocations entirely, negating this advantage.
TooManyCooks offers the best performance possible without making any usability sacrifices.
# Killer Feature #1 - CPU Topology Detection
As every major CPU manufacturer is now exploring disaggregated / hybrid architectures, legacy work-stealing designs are showing their age. TooManyCooks is designed for this new era of hardware.
It uses the CPU topology information exposed by the [libhwloc](https://www.open-mpi.org/projects/hwloc/) library to implement the following automatic behaviors:
* ([docs](https://www.fleetcode.com/oss/tmc/docs/v1.4/executors/ex_cpu.html#hardware-optimized-defaults)) locality-aware work stealing for disaggregated caches (e.g. Zen chiplet architecture).
* ([docs](https://www.fleetcode.com/oss/tmc/docs/v1.4/executors/topology.html#_CPPv4N3tmc8topology12cpu_topology19container_cpu_quotaE)) Linux cgroups detection sets the number of threads according to the CPU quota when running in a container
* If the CPU quota is set instead by selecting specific cores (`--cpuset-cpus`) or with [Kubernetes Guaranteed QoS](https://docs.starlingx.io/r/stx.6.0/usertasks/kubernetes/using-kubernetes-cpu-manager-static-policy.html), the hwloc integration will detect the allowed cores (and their cache hierarchy!) and create locality-aware work stealing groups as if running on bare metal.
Additionally, the topology can be queried by the user ([docs](https://www.fleetcode.com/oss/tmc/docs/v1.4/executors/topology.html)) ([example](https://github.com/tzcnt/tmc-examples/blob/44ce66de8e74107c803645c82ddd88a7be35fd29/examples/hwloc/topo.cpp)) and APIs are provided that let you do powerful things:
*
Harald Achitz: About Generator, Ranges, and Simplicity
https://youtu.be/Bdwh4u4xF_o
https://redd.it/1qsu5nd
@r_cpp