A quick C++ standard container overview
https://meetingcpp.com/blog/items/A-quick-Cpp-standard-container-overview.html
https://redd.it/1x86iky
@r_cpp
https://meetingcpp.com/blog/items/A-quick-Cpp-standard-container-overview.html
https://redd.it/1x86iky
@r_cpp
"C++23 - The Complete Guide" now as Paperback
C++23 - The Complete Guide is now also available as paperback version.
You can order it, for example, at Amazon.
The book explains on 500 pages all new features of C++23 (covering both the core language and the standard library) with motivation, conceptional introduction of all aspects, and many examples of how to use the new features in practice.
The book is part of my "The Complete Guide" Series, trying to explain a programming language that is now so overwhelming that as a programmer it is hard to keep track of all its new features, benefits, and pitfalls.
Enjoy
Nico
https://redd.it/1x5q76a
@r_cpp
C++23 - The Complete Guide is now also available as paperback version.
You can order it, for example, at Amazon.
The book explains on 500 pages all new features of C++23 (covering both the core language and the standard library) with motivation, conceptional introduction of all aspects, and many examples of how to use the new features in practice.
The book is part of my "The Complete Guide" Series, trying to explain a programming language that is now so overwhelming that as a programmer it is hard to keep track of all its new features, benefits, and pitfalls.
Enjoy
Nico
https://redd.it/1x5q76a
@r_cpp
Amazon
C++23 - The Complete Guide
Amazon.com: C++23 - The Complete Guide: 9783967300239: Josuttis, Nicolai M.: Books
C++ Under the sea conference
I just attended the C++ Under the Sea 2-day conference. I really enjoyed it. Watch out for talks from Hana, Matt and Kevin Henney. Really good keynotes
Matt presented his v4 version of this ZX Spectrum emulator: https://github.com/mattgodbolt/specbolt
Both Kevin Henney's and Hana's talks were new; at least I haven't seen a version of them before. These keynotes were really, really good. Hope it comes on YouTube soon.
Personally, I was a bit let down by talks from people who work for AI companies. The talks became more like a product user guide than anything to do with C++ or Programming.
Overall, an amazing conference. If you are in and around the Netherlands, you should plan to attend.
https://redd.it/1x8804j
@r_cpp
I just attended the C++ Under the Sea 2-day conference. I really enjoyed it. Watch out for talks from Hana, Matt and Kevin Henney. Really good keynotes
Matt presented his v4 version of this ZX Spectrum emulator: https://github.com/mattgodbolt/specbolt
Both Kevin Henney's and Hana's talks were new; at least I haven't seen a version of them before. These keynotes were really, really good. Hope it comes on YouTube soon.
Personally, I was a bit let down by talks from people who work for AI companies. The talks became more like a product user guide than anything to do with C++ or Programming.
Overall, an amazing conference. If you are in and around the Netherlands, you should plan to attend.
https://redd.it/1x8804j
@r_cpp
GitHub
GitHub - mattgodbolt/specbolt: Yet another ZX Spectrum Emulator
Yet another ZX Spectrum Emulator. Contribute to mattgodbolt/specbolt development by creating an account on GitHub.
A Cross Toolkit Animation Timeline Control
https://www.youtube.com/watch?v=131P4BNCTbI
https://redd.it/1x6n20n
@r_cpp
https://www.youtube.com/watch?v=131P4BNCTbI
https://redd.it/1x6n20n
@r_cpp
YouTube
A Cross Toolkit Animation Timeline Control
Sometimes you need a custom GUI control for your application and you think "other people could probably use this". Usually this means that the people using your control must use the same GUI toolkit as you: wxWidgets, Qt, ImGui, etc.
Can we write a control…
Can we write a control…
A C++ Trick Question - Blog Post
https://greenlightning.eu/programming/cpp-trick-question/
https://redd.it/1x62vjq
@r_cpp
https://greenlightning.eu/programming/cpp-trick-question/
https://redd.it/1x62vjq
@r_cpp
Green Lightning
A C++ Trick Question
Let’s jump right in; the answer and explanation are hidden after the code.
Assuming all allocations succeed, can the following function still crash? Why? …
Assuming all allocations succeed, can the following function still crash? Why? …
Please consider bundling C++ STL with your application
Systems targeted by C++ toolchains vary a lot even though C++ constantly changes. If you rely on operating system STL for your application code, following things may happen:
- If your platform A supports C++20 and your platform B supports C++14 and your platform C supports C++11, you will either force C++ <= 11 to all your libraries, or use macro magic etc, to use one set of features each platform.
- If you operate in a specialized domain, such as real-time systems, you may need a standard library built with specific configuration options, such as disabling exceptions or RTTI. Relying on the system-provided STL leaves you dependent on how it was built, which may not meet your requirements
If you build your STL of choice you solve all these issues:
- You can use the highest C++ standard possible, you no longer have to think about each operating system state extensively.
- You can configure your STL to match your needs
In nearly all modern system languages you build standard library yourself, I don't see any reason why C++ developers shouldn't consider this.
https://redd.it/1x6zfqy
@r_cpp
Systems targeted by C++ toolchains vary a lot even though C++ constantly changes. If you rely on operating system STL for your application code, following things may happen:
- If your platform A supports C++20 and your platform B supports C++14 and your platform C supports C++11, you will either force C++ <= 11 to all your libraries, or use macro magic etc, to use one set of features each platform.
- If you operate in a specialized domain, such as real-time systems, you may need a standard library built with specific configuration options, such as disabling exceptions or RTTI. Relying on the system-provided STL leaves you dependent on how it was built, which may not meet your requirements
If you build your STL of choice you solve all these issues:
- You can use the highest C++ standard possible, you no longer have to think about each operating system state extensively.
- You can configure your STL to match your needs
In nearly all modern system languages you build standard library yourself, I don't see any reason why C++ developers shouldn't consider this.
https://redd.it/1x6zfqy
@r_cpp
Reddit
From the cpp community on Reddit
Explore this post and more from the cpp community
Which API design should my framework have?
right now in vexa(my game/graphics library) how you initialize window with a renderer is rather straightforward:
```cpp
\#include <vexa/vexa.hpp>
using namespace vexa;
int main()
{
Engine::Init(Engine::VIDEO);
Window window = Window().setSize({1280, 720}).setRenderer({}).create();
// ...
```
YES, it uses builder pattern, not very C++-ish but i like it.
However, there are two problems with it.
first one is that usually you have builder struct building to target type so that you dont need something like `.create()` that creates classic `if (m_created) ...` problem a.k.a two phase construction. but bigger problem that caused me two want to switch to this API style is about memory management. and it is now C++'s problem.. Even rust cant handle it, because this is what you tell it to do.
so lets dont talk too much:
```cpp
Engine::Init(Engine::FONT); // calls `TTF_Init();` by SDL_TTF behind the scenes
Font font = Font::Load("...");
...
Engine::Quit();
```
A Font has destructor running on scope exit. which means before font object gets destroyed on '}' Engine::Quit() so TTF_Quit() runs. You see, when Font object gets unloaded at scope end the subsystem is not live anymore, we get a segfault. to fix this i've made Engine have a Guard struct which does Engine::Quit() automatically. But then decided that this is not i want for my API. I would priorotize explicitness for the master deinitialization.
to fix this im thinking of new API design style:
```cpp
Window window = Engine::BuildWindow().setSize({1280, 720}).setRenderer().create();
```
where BuildWindow() returns WindowBuilder not a Window, unlike the previous(so bad) choice.
for fonts, as you might already guess:
```cpp
Font font = Engine::LoadFont("...");
```
which creates a font and returns reference to it, resulting Engine to know about font count and Quit or not based on that.
code: https://github.com/monjaris/vexa
https://redd.it/1x8gtg7
@r_cpp
right now in vexa(my game/graphics library) how you initialize window with a renderer is rather straightforward:
```cpp
\#include <vexa/vexa.hpp>
using namespace vexa;
int main()
{
Engine::Init(Engine::VIDEO);
Window window = Window().setSize({1280, 720}).setRenderer({}).create();
// ...
```
YES, it uses builder pattern, not very C++-ish but i like it.
However, there are two problems with it.
first one is that usually you have builder struct building to target type so that you dont need something like `.create()` that creates classic `if (m_created) ...` problem a.k.a two phase construction. but bigger problem that caused me two want to switch to this API style is about memory management. and it is now C++'s problem.. Even rust cant handle it, because this is what you tell it to do.
so lets dont talk too much:
```cpp
Engine::Init(Engine::FONT); // calls `TTF_Init();` by SDL_TTF behind the scenes
Font font = Font::Load("...");
...
Engine::Quit();
```
A Font has destructor running on scope exit. which means before font object gets destroyed on '}' Engine::Quit() so TTF_Quit() runs. You see, when Font object gets unloaded at scope end the subsystem is not live anymore, we get a segfault. to fix this i've made Engine have a Guard struct which does Engine::Quit() automatically. But then decided that this is not i want for my API. I would priorotize explicitness for the master deinitialization.
to fix this im thinking of new API design style:
```cpp
Window window = Engine::BuildWindow().setSize({1280, 720}).setRenderer().create();
```
where BuildWindow() returns WindowBuilder not a Window, unlike the previous(so bad) choice.
for fonts, as you might already guess:
```cpp
Font font = Engine::LoadFont("...");
```
which creates a font and returns reference to it, resulting Engine to know about font count and Quit or not based on that.
code: https://github.com/monjaris/vexa
https://redd.it/1x8gtg7
@r_cpp
GitHub
GitHub - monjaris/vexa: Modern cross-platform game/graphics framework written in C++23
Modern cross-platform game/graphics framework written in C++23 - monjaris/vexa
I can't use generic lambdas at compile-time, now what? - Braden Ganetsky
https://blog.ganets.ky/ClangGenericLambdas/
https://redd.it/1x8kbqg
@r_cpp
https://blog.ganets.ky/ClangGenericLambdas/
https://redd.it/1x8kbqg
@r_cpp
blog.ganets.ky
I can't use generic lambdas at compile-time, now what?
2026-10-11
Misreading code when tired
This was a first time for me, IIRC. It fooled me especially well with the light red syntax highlighting I'm using in macOS Terminal.
I misread static_cast<> as "satanic cast" and realized I should go to bed.
https://redd.it/1x8q05m
@r_cpp
This was a first time for me, IIRC. It fooled me especially well with the light red syntax highlighting I'm using in macOS Terminal.
I misread static_cast<> as "satanic cast" and realized I should go to bed.
https://redd.it/1x8q05m
@r_cpp
Reddit
From the cpp community on Reddit
Explore this post and more from the cpp community
The intention and spirit behind modules seem diametrically opposed to their actual implementations by compiler toolchains.
The lynchpin of C++ modules is the built module interface (BMI). Each BMI is meant to be a lightweight data structure representing the syntax of a module unit (comprised of one primary module interface and potentially one or more partitions), with approximately O(1) complexity of symbol lookup. This massively accelerates repeated lookups into the same translation unit, and avoids paying the cost of a full preprocessor run and front-end lex + parse, as might otherwise happen with header files. In this way both the first clean build, and incremental builds are considerably accelerated and made much more efficient—build the BMI once, reuse it across future compiles, and we don't need large core counts and massively parallel jobs because the BMI is now available afterwards.
However, the way compiler toolchains have actually implemented them seems diametrically opposed to this goal of fast lookup. Today, BMIs are highly sensitive to any change in the command-line invocation of the compiler/dependency scanning tool, including the C++ version, warning and feature flags, and especially macro definitions, with
BMIs are considered implementation details, and aren't even stable across compiler versions within the same toolchain. Compare to object files, where something compiled by really old versions can still be used on newer versions without too much fuss. This, from the user's perspective, entirely defeats that design ideal mentioned above: fast repeated lookups. Consider a simple example: a certain module uses a project-specific macro representing the platform, to change several function signatures. This module is now precompiled thrice, once each for
I believe that macros and the preprocessor are highly problematic. However, their very limitations are also an advantage here: their effect on code collapses to completely binary decisions. A macro is either defined or not, and a macro is either in the set of accepted values, or it isn't (e.g.
This would make things like library feature configuration with macros really straightforward—specify the macros one wants for that feature at the command-line, which is enshrined in build system code rather than source code—the BMI can be reused, done.
Now, the compiler and C++ standard are a lot harder as these probably affect the internal state of the compiler rather than merely the value of
As mentioned above, build systems are also forced into this rather inefficient model to accommodate compiler behaviour. CMake in its latest
The lynchpin of C++ modules is the built module interface (BMI). Each BMI is meant to be a lightweight data structure representing the syntax of a module unit (comprised of one primary module interface and potentially one or more partitions), with approximately O(1) complexity of symbol lookup. This massively accelerates repeated lookups into the same translation unit, and avoids paying the cost of a full preprocessor run and front-end lex + parse, as might otherwise happen with header files. In this way both the first clean build, and incremental builds are considerably accelerated and made much more efficient—build the BMI once, reuse it across future compiles, and we don't need large core counts and massively parallel jobs because the BMI is now available afterwards.
However, the way compiler toolchains have actually implemented them seems diametrically opposed to this goal of fast lookup. Today, BMIs are highly sensitive to any change in the command-line invocation of the compiler/dependency scanning tool, including the C++ version, warning and feature flags, and especially macro definitions, with
-DMACRO or /DMACRO. This means that changing just one flag is likely to cause a BMI cache miss and a full BMI reconstruction, which can be fairly slow for larger modules (like module std).BMIs are considered implementation details, and aren't even stable across compiler versions within the same toolchain. Compare to object files, where something compiled by really old versions can still be used on newer versions without too much fuss. This, from the user's perspective, entirely defeats that design ideal mentioned above: fast repeated lookups. Consider a simple example: a certain module uses a project-specific macro representing the platform, to change several function signatures. This module is now precompiled thrice, once each for
-DFOO_WINDOWS, -DFOO_DARWIN, -DFOO_LINUX, instead of just once.I believe that macros and the preprocessor are highly problematic. However, their very limitations are also an advantage here: their effect on code collapses to completely binary decisions. A macro is either defined or not, and a macro is either in the set of accepted values, or it isn't (e.g.
#if __cplusplus >= 202603L). The preprocessor state might change throughout the source code of a translation unit, but the entire set of possible states can be enumerated in finite and reasonably short time at compile time—otherwise the front-end would never complete its work. To me, this seems like the preprocessor and parser could enumerate all possible preprocessor states of the source code, and stamp out both possibilities for each macro switch in the BMI; during lookup, the compiler can select the correct code path depending on what is provided at that particular invocation (not code definitions, but command-line invocations, as this would break the module assurance that macros do not leak into BMIs from consumers, nor do consumers see macros from a BMI). This would make things like library feature configuration with macros really straightforward—specify the macros one wants for that feature at the command-line, which is enshrined in build system code rather than source code—the BMI can be reused, done.
Now, the compiler and C++ standard are a lot harder as these probably affect the internal state of the compiler rather than merely the value of
__cplusplus; however, I genuinely feel like there really ought to be a better way forward, especially if C++ is to continue as a 'source may not be available' language. This discussion is moot if we always want to compile from source, but I want to say that is wasteful, and another driving force of the modules feature was to do away with wasteful and repeated recomputation of the same thing.As mentioned above, build systems are also forced into this rather inefficient model to accommodate compiler behaviour. CMake in its latest
iteration, for instance, has a notion of 'BMI compatibility', and probably does some sort of set manipulation on compile flags to determine if another BMI for the same module interface is needed or not, based on how it is
I'm sure I don't have the entire picture as I am not a compiler front-end developer, and I don't mean to sound impertinent here, the effort put into delivering modules has been huge. However there are some decisions made which, as modules user and advocate, seem a little contradictory to the spirit of modules. I've written this after some thought on the situation and I'm interested in hearing from the community and compiler front-end developers who have worked on modules on my thoughts above.
Cheers.
https://redd.it/1x9famy
@r_cpp
imported. Why? This shouldn't be the case, a BMI really ought to be widely (if not universally) compatible, regardless of what flags go in the command-line. I'm sure I don't have the entire picture as I am not a compiler front-end developer, and I don't mean to sound impertinent here, the effort put into delivering modules has been huge. However there are some decisions made which, as modules user and advocate, seem a little contradictory to the spirit of modules. I've written this after some thought on the situation and I'm interested in hearing from the community and compiler front-end developers who have worked on modules on my thoughts above.
Cheers.
https://redd.it/1x9famy
@r_cpp
Reddit
From the cpp community on Reddit
Explore this post and more from the cpp community
4 compilers and 3 different results when partially/fully specializing member class template of a class template
I was playing with examples from cppreference, specifically https://cppreference.com/cpp/language/partial_specialization at the bottom in order to understand specialization deeper and form some notes. Maybe even at some point put out a template guide on my website.
Last 2 statements describe very similar situation but the order of words in each sentence is so different and the example so narrow that I had trouble figuring out what these really mean:
> If the primary member template is explicitly (fully) specialized for a given (implicit) specialization of the enclosing class template, the partial specializations of the member template are ignored for this specialization of the enclosing class template.
> If a partial specialization of the member template is explicitly specialized for a given (implicit) specialization of the enclosing class template, the primary member template and its other partial specializations are still considered for this specialization of the enclosing class template.
Eventually I managed to figure out the example only showcases the first statement and that the difference between these 2 situations is this:
- `struct A<short>::B {};` - full spec of member B template for implicitly-instantiated A template (replaces all B for A<short>)
- `struct A<short>::B<T&> {};` - partial spec of member B template for implicitly-instantiated A template (adds another spec to A<short>, merging it with specs from primary A template)
To confirm I reason correctly, I wrote some sample code to have a more comprehensive example. I did not expect to encounter 3 different outputs from 4 different compilers. And I don't think you can reach UB on templates alone.
https://godbolt.org/z/8z7vde1PE
So which one is correct (if any - maybe it's *ill-formed no diagnostic required*)? The comments are my expectations, the question marks are places where compilers disagree.
Also, member specialization isn't even a C++11 feature. Compiler bugs in something so old and fundamental (and supposedly easy to unit-test) ... I have no words.
https://redd.it/1x9tx4m
@r_cpp
I was playing with examples from cppreference, specifically https://cppreference.com/cpp/language/partial_specialization at the bottom in order to understand specialization deeper and form some notes. Maybe even at some point put out a template guide on my website.
Last 2 statements describe very similar situation but the order of words in each sentence is so different and the example so narrow that I had trouble figuring out what these really mean:
> If the primary member template is explicitly (fully) specialized for a given (implicit) specialization of the enclosing class template, the partial specializations of the member template are ignored for this specialization of the enclosing class template.
> If a partial specialization of the member template is explicitly specialized for a given (implicit) specialization of the enclosing class template, the primary member template and its other partial specializations are still considered for this specialization of the enclosing class template.
Eventually I managed to figure out the example only showcases the first statement and that the difference between these 2 situations is this:
- `struct A<short>::B {};` - full spec of member B template for implicitly-instantiated A template (replaces all B for A<short>)
- `struct A<short>::B<T&> {};` - partial spec of member B template for implicitly-instantiated A template (adds another spec to A<short>, merging it with specs from primary A template)
To confirm I reason correctly, I wrote some sample code to have a more comprehensive example. I did not expect to encounter 3 different outputs from 4 different compilers. And I don't think you can reach UB on templates alone.
https://godbolt.org/z/8z7vde1PE
So which one is correct (if any - maybe it's *ill-formed no diagnostic required*)? The comments are my expectations, the question marks are places where compilers disagree.
Also, member specialization isn't even a C++11 feature. Compiler bugs in something so old and fundamental (and supposedly easy to unit-test) ... I have no words.
https://redd.it/1x9tx4m
@r_cpp
C++/Java interoperability and system failures at WAWTech — Warsaw, 26–27 November
Hi there! I am working with the organising team for WAWTech. Its two-day software and product development conference and takes place at EXPO XXI in Warsaw on 26–27 November 2026.
Want to share two talks from the programme that may be relevant here:
First one is Denys Makogon, Oracle — “The Modern Challenge of Integrating C++ into the Java Ecosystem: Problems, Consequences, and Solutions”. The talk looks at what happens when Java applications need to use C++ libraries (OpenCV or OpenVINO). It covers differences in memory models, object lifetimes and error handling, and how to build a reliable bridge between the two languages.
Second one is Paweł Romul — “Your System Will Fail. What Now?”. Its a broader architecture talk examining two real incidents and the decisions that led to very different outcomes. This one isn’t C++-specific, but i think may interest people working on systems where failure handling shapes the design :)
Event details if you’re considering attending.
https://redd.it/1x9vpqz
@r_cpp
Hi there! I am working with the organising team for WAWTech. Its two-day software and product development conference and takes place at EXPO XXI in Warsaw on 26–27 November 2026.
Want to share two talks from the programme that may be relevant here:
First one is Denys Makogon, Oracle — “The Modern Challenge of Integrating C++ into the Java Ecosystem: Problems, Consequences, and Solutions”. The talk looks at what happens when Java applications need to use C++ libraries (OpenCV or OpenVINO). It covers differences in memory models, object lifetimes and error handling, and how to build a reliable bridge between the two languages.
Second one is Paweł Romul — “Your System Will Fail. What Now?”. Its a broader architecture talk examining two real incidents and the decisions that led to very different outcomes. This one isn’t C++-specific, but i think may interest people working on systems where failure handling shapes the design :)
Event details if you’re considering attending.
https://redd.it/1x9vpqz
@r_cpp
WAWTech
WAWTech 2026 | WAWTech
November 26-27 in Warsaw, WAWTech 2026 — Tech conference in Warsaw for 3000 Engineers
New C++ Conference Videos Released This Month - October 2026 (Updated To Include Videos Released 2026-10-12 - 2026-10-18)
**C++Now**
2026-10-12 - 2026-10-18
* Implementing Logic in C++ - Hans de Nivelle - [https://youtu.be/3ffgtI31iKw](https://youtu.be/3ffgtI31iKw)
* The Secret to C++ Reflection Now: CMake Code Generation - Bret Brown - [https://youtu.be/OW\_h9oyHQ-0](https://youtu.be/OW_h9oyHQ-0)
* Co-Designing Integrated AI-Enabled Compiler-Runtime Systems - Hartmut Kaiser - [https://youtu.be/cIt4D\_SJcI8](https://youtu.be/cIt4D_SJcI8)
2026-10-05 - 2026-10-11
* Signal Trees - A Deep Dive into a High-Performance Alternative to Queue-Based Task Scheduling - Michael Maniscalco - [https://youtu.be/ZRd\_XN3LGxo](https://youtu.be/ZRd_XN3LGxo)
* Object Oriented Programming in Contemporary C++ - Steve Downey - [https://youtu.be/m7gwSr27m74](https://youtu.be/m7gwSr27m74)
* Cutting Some Slack for our Programs - Lisa Lippincott - [https://youtu.be/xwnRPyRK5h4](https://youtu.be/xwnRPyRK5h4)
2026-09-28 - 2026-10-04
* What Every C++ Programmer Needs to Know About AI - Jody Hagins - [https://youtu.be/ZBXHPKVCa8E](https://youtu.be/ZBXHPKVCa8E)
* SPL - Open Source, Constexpr Library for Composing Algorithms - John Bandela - [https://youtu.be/96AGjm3uwko](https://youtu.be/96AGjm3uwko)
* Senders For Existing Asynchronous Interfaces - Dietmar Kühl - [https://youtu.be/KB5Nfofgu2k](https://youtu.be/KB5Nfofgu2k)
**ACCU**
2026-10-12 - 2026-10-18
* Dependency Injection and Dependency Inversion - C++ Perspective - Vladimir Vishnevskii - [https://youtu.be/hzD9k4BZCE4](https://youtu.be/hzD9k4BZCE4)
* AI Writes All Your Code Now - How Will You Ever Debug It? - Greg Law & Mark Williamson - [https://youtu.be/-hTG9Jp\_2PU](https://youtu.be/-hTG9Jp_2PU)
* The Not-So-Hidden Corners of C++ ABI Stability - Luis Caro Campos - [https://youtu.be/3nd4RIH5okA](https://youtu.be/3nd4RIH5okA)
2026-10-05 - 2026-10-11
* Real-time Safety in C & C++ - Guaranteed by the Compiler! - Anders Schau Knatten - [https://youtu.be/FeYEO3PhEVY](https://youtu.be/FeYEO3PhEVY)
* Modernizing Legacy Codebases Without Stopping the World - Peter Muldoon - [https://youtu.be/w9k-L0GLLKM](https://youtu.be/w9k-L0GLLKM)
* Our Journey Toward a Fully Backward-Compatible, UB-Safe, ISO C++ - John Lakos - [https://youtu.be/whFzmXXhG5g](https://youtu.be/whFzmXXhG5g)
2026-09-28 - 2026-10-04
* Refactoring Towards Structured Concurrency - Roi Barkan - [https://youtu.be/ttoQfPP\_Gkg](https://youtu.be/ttoQfPP_Gkg)
* Design Patterns - The Most Common Misconceptions (3 of N) - Klaus Iglberger - [https://youtu.be/bAsJvmtYZOg](https://youtu.be/bAsJvmtYZOg)
* One Lib to Rule Them All and in the Darkness bindgen… - Antonello Palazzi & Kay Hicketts - [https://youtu.be/9BpVjPKv02s](https://youtu.be/9BpVjPKv02s)
**ADC**
2026-10-12 - 2026-10-18
* Introduction of the Technologies That Make Up Project LYDIA - Taichi Kumon & Tom Baker - [https://youtu.be/-Cyht3g4H1s](https://youtu.be/-Cyht3g4H1s)
* AI for Circuit Modeling - 村井 勝吾 / Shogo Murai - [https://youtu.be/IL08vd0EiFY](https://youtu.be/IL08vd0EiFY)
* MIDI 2.0 - Ready to Ship - Brett g Porter - [https://youtu.be/RGLtRZC--34](https://youtu.be/RGLtRZC--34)
2026-10-05 - 2026-10-11
* BEEPS and PORTS - Annoy Everyone in Your House While Building An Audio Synthesizer - Joseph Stewart - [https://youtu.be/bnIV2nyh-rg](https://youtu.be/bnIV2nyh-rg)
* Hardware DSP Asset Inheritance and Evolution - Takeshi Kuwahara - [https://youtu.be/yYukJpiFOOU](https://youtu.be/yYukJpiFOOU)
* Field Recording - In Search for Perfect Sounds - Malin Arvidsson - [https://youtu.be/L5iZDi71VWU](https://youtu.be/L5iZDi71VWU)
2026-09-28 - 2026-10-04
* Designing Interactive Music Experiences in XR - Kasson Crooker - [https://youtu.be/J3sVHT8luKs](https://youtu.be/J3sVHT8luKs)
* When (Not) to Patent Audio Software - Simon Hestermann - [https://youtu.be/stBB1JoKQiY](https://youtu.be/stBB1JoKQiY)
* Distribution Strategies for Indie Audio Developers - From Plugin to Product - Dani Karanyi -
**C++Now**
2026-10-12 - 2026-10-18
* Implementing Logic in C++ - Hans de Nivelle - [https://youtu.be/3ffgtI31iKw](https://youtu.be/3ffgtI31iKw)
* The Secret to C++ Reflection Now: CMake Code Generation - Bret Brown - [https://youtu.be/OW\_h9oyHQ-0](https://youtu.be/OW_h9oyHQ-0)
* Co-Designing Integrated AI-Enabled Compiler-Runtime Systems - Hartmut Kaiser - [https://youtu.be/cIt4D\_SJcI8](https://youtu.be/cIt4D_SJcI8)
2026-10-05 - 2026-10-11
* Signal Trees - A Deep Dive into a High-Performance Alternative to Queue-Based Task Scheduling - Michael Maniscalco - [https://youtu.be/ZRd\_XN3LGxo](https://youtu.be/ZRd_XN3LGxo)
* Object Oriented Programming in Contemporary C++ - Steve Downey - [https://youtu.be/m7gwSr27m74](https://youtu.be/m7gwSr27m74)
* Cutting Some Slack for our Programs - Lisa Lippincott - [https://youtu.be/xwnRPyRK5h4](https://youtu.be/xwnRPyRK5h4)
2026-09-28 - 2026-10-04
* What Every C++ Programmer Needs to Know About AI - Jody Hagins - [https://youtu.be/ZBXHPKVCa8E](https://youtu.be/ZBXHPKVCa8E)
* SPL - Open Source, Constexpr Library for Composing Algorithms - John Bandela - [https://youtu.be/96AGjm3uwko](https://youtu.be/96AGjm3uwko)
* Senders For Existing Asynchronous Interfaces - Dietmar Kühl - [https://youtu.be/KB5Nfofgu2k](https://youtu.be/KB5Nfofgu2k)
**ACCU**
2026-10-12 - 2026-10-18
* Dependency Injection and Dependency Inversion - C++ Perspective - Vladimir Vishnevskii - [https://youtu.be/hzD9k4BZCE4](https://youtu.be/hzD9k4BZCE4)
* AI Writes All Your Code Now - How Will You Ever Debug It? - Greg Law & Mark Williamson - [https://youtu.be/-hTG9Jp\_2PU](https://youtu.be/-hTG9Jp_2PU)
* The Not-So-Hidden Corners of C++ ABI Stability - Luis Caro Campos - [https://youtu.be/3nd4RIH5okA](https://youtu.be/3nd4RIH5okA)
2026-10-05 - 2026-10-11
* Real-time Safety in C & C++ - Guaranteed by the Compiler! - Anders Schau Knatten - [https://youtu.be/FeYEO3PhEVY](https://youtu.be/FeYEO3PhEVY)
* Modernizing Legacy Codebases Without Stopping the World - Peter Muldoon - [https://youtu.be/w9k-L0GLLKM](https://youtu.be/w9k-L0GLLKM)
* Our Journey Toward a Fully Backward-Compatible, UB-Safe, ISO C++ - John Lakos - [https://youtu.be/whFzmXXhG5g](https://youtu.be/whFzmXXhG5g)
2026-09-28 - 2026-10-04
* Refactoring Towards Structured Concurrency - Roi Barkan - [https://youtu.be/ttoQfPP\_Gkg](https://youtu.be/ttoQfPP_Gkg)
* Design Patterns - The Most Common Misconceptions (3 of N) - Klaus Iglberger - [https://youtu.be/bAsJvmtYZOg](https://youtu.be/bAsJvmtYZOg)
* One Lib to Rule Them All and in the Darkness bindgen… - Antonello Palazzi & Kay Hicketts - [https://youtu.be/9BpVjPKv02s](https://youtu.be/9BpVjPKv02s)
**ADC**
2026-10-12 - 2026-10-18
* Introduction of the Technologies That Make Up Project LYDIA - Taichi Kumon & Tom Baker - [https://youtu.be/-Cyht3g4H1s](https://youtu.be/-Cyht3g4H1s)
* AI for Circuit Modeling - 村井 勝吾 / Shogo Murai - [https://youtu.be/IL08vd0EiFY](https://youtu.be/IL08vd0EiFY)
* MIDI 2.0 - Ready to Ship - Brett g Porter - [https://youtu.be/RGLtRZC--34](https://youtu.be/RGLtRZC--34)
2026-10-05 - 2026-10-11
* BEEPS and PORTS - Annoy Everyone in Your House While Building An Audio Synthesizer - Joseph Stewart - [https://youtu.be/bnIV2nyh-rg](https://youtu.be/bnIV2nyh-rg)
* Hardware DSP Asset Inheritance and Evolution - Takeshi Kuwahara - [https://youtu.be/yYukJpiFOOU](https://youtu.be/yYukJpiFOOU)
* Field Recording - In Search for Perfect Sounds - Malin Arvidsson - [https://youtu.be/L5iZDi71VWU](https://youtu.be/L5iZDi71VWU)
2026-09-28 - 2026-10-04
* Designing Interactive Music Experiences in XR - Kasson Crooker - [https://youtu.be/J3sVHT8luKs](https://youtu.be/J3sVHT8luKs)
* When (Not) to Patent Audio Software - Simon Hestermann - [https://youtu.be/stBB1JoKQiY](https://youtu.be/stBB1JoKQiY)
* Distribution Strategies for Indie Audio Developers - From Plugin to Product - Dani Karanyi -
YouTube
Implementing Logic in C++ - Hans de Nivelle - C++Now 2026
https://www.cppnow.org
---
Implementing Logic in C++ - Hans de Nivelle - C++Now 2026
---
For most logicians, C++ will not be the language of choice for implementing their algorithms. In the best case, they will admit that using an imperative language like…
---
Implementing Logic in C++ - Hans de Nivelle - C++Now 2026
---
For most logicians, C++ will not be the language of choice for implementing their algorithms. In the best case, they will admit that using an imperative language like…
I made a job board that only lists C++ jobs
Every time I went looking for a new job position I'd lose hours scrolling past "C/C++/C#" listings, recruiter reposts, and jobs where C++ was keyword.
So I built cppjobs.dev. It's pretty simple. It only lists jobs where C++ is actually a big part of the work, and I check every post myself before it goes up. You can filter by location, remote/hybrid/on-site, contract type and salary, or sign up for email alerts if you don't want to keep checking. Apply goes straight to the company. I'm not a recruiter and never see your CV. No accounts, no ads, no tracking cookies.
It just launched it this morning, so honestly there aren't many jobs on it yet. If you're hiring C++ people, posting is free for now and I'd really appreciate it.
Mostly I'd love to hear what bugs you about the job boards you use now. What would make you actually use this one?
https://redd.it/1xa7l9k
@r_cpp
Every time I went looking for a new job position I'd lose hours scrolling past "C/C++/C#" listings, recruiter reposts, and jobs where C++ was keyword.
So I built cppjobs.dev. It's pretty simple. It only lists jobs where C++ is actually a big part of the work, and I check every post myself before it goes up. You can filter by location, remote/hybrid/on-site, contract type and salary, or sign up for email alerts if you don't want to keep checking. Apply goes straight to the company. I'm not a recruiter and never see your CV. No accounts, no ads, no tracking cookies.
It just launched it this morning, so honestly there aren't many jobs on it yet. If you're hiring C++ people, posting is free for now and I'd really appreciate it.
Mostly I'd love to hear what bugs you about the job boards you use now. What would make you actually use this one?
https://redd.it/1xa7l9k
@r_cpp
What makes a game tick? Part 9.5 - The Curse of the Scheduler Latency · Mathieu Ropert
https://mropert.github.io/2026/10/20/making_games_tick_part9_5/
https://redd.it/1xanf72
@r_cpp
https://mropert.github.io/2026/10/20/making_games_tick_part9_5/
https://redd.it/1xanf72
@r_cpp
mropert.github.io
What makes a game tick? Part 9.5 - The Curse of the Scheduler Latency · Mathieu Ropert
Let’s talk about game simulations. Today I bring up a slightly more advanced topic and talk about OS scheduler latency and its impact on multi-threaded tick design.
variable-length demangler for mangled C++ names
https://github.com/core-explorer/itanium-demangler
https://redd.it/1xb0yq7
@r_cpp
https://github.com/core-explorer/itanium-demangler
https://redd.it/1xb0yq7
@r_cpp
GitHub
GitHub - core-explorer/itanium-demangler: C++ demangler for the itanium ABI written in C++
C++ demangler for the itanium ABI written in C++. Contribute to core-explorer/itanium-demangler development by creating an account on GitHub.