C++Day

2026-10-19 - 2026-10-25

• C++26 Execution Control: An Introduction (Alberto Barbati) - https://www.youtube.com/watch?v=U4b8yO5L5JY
• Interesting Allocators in Games (Sergei Kushnirenko) - https://www.youtube.com/watch?v=6fWwaLMgC94
• From legacy code to a registry of modern algorithms (Roberta Cisotti) - https://www.youtube.com/watch?v=u_FZatqHFAk
• Zero-Overhead Dispatch: Leveraging __musttail and Custom ABI in C++ - https://www.youtube.com/watch?v=2N7ALplaMC4&pp=0gcJCTAMAYcqIYzv

C++Now

2026-10-19 - 2026-10-25

• C++ Magic Statics Demystified - History, Internals, Pitfalls, and Optimizations - Chandranath Bhattacharyya - https://youtu.be/kV6TbuRMIVg
• Code C++ Like a Library Author - Jon Kalb - https://youtu.be/LgTEvW61J70
• CMake’s Recent Evolution - Modules, CPS, and Build Optimization - Bill Hoffman - https://youtu.be/aas2DSxHrT8

2026-10-12 - 2026-10-18

• Implementing Logic in C++ - Hans de Nivelle - https://youtu.be/3ffgtI31iKw
• The Secret to C++ Reflection Now: CMake Code Generation - Bret Brown - https://youtu.be/OW_h9oyHQ-0
• Co-Designing Integrated AI-Enabled Compiler-Runtime Systems - Hartmut Kaiser - 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
• Object Oriented Programming in Contemporary C++ - Steve Downey - https://youtu.be/m7gwSr27m74
• Cutting Some Slack for our Programs - Lisa Lippincott - 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
• SPL - Open Source, Constexpr Library for Composing Algorithms - John Bandela - https://youtu.be/96AGjm3uwko
• Senders For Existing Asynchronous Interfaces - Dietmar Kühl - https://youtu.be/KB5Nfofgu2k

ACCU

2026-10-19 - 2026-10-25

• Serial C++ Can Be Parallel Too - Eran Gilad - https://youtu.be/4amZ_ZWqpA8
• C++ Magic Statics Demystified - History, Internals, Pitfalls, and Optimizations - Kathleen Baker & Chandranath Bhattacharyya - https://youtu.be/h40xp211BCw
• What static, inline, const, constexpr Mean and When to Use Them - Andreas Fertig - https://youtu.be/u8te1UQOxQY

2026-10-12 - 2026-10-18

• Dependency Injection and Dependency Inversion - C++ Perspective - Vladimir Vishnevskii - 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
• The Not-So-Hidden Corners of C++ ABI Stability - Luis Caro Campos - 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
• Modernizing Legacy Codebases Without Stopping the World - Peter Muldoon - https://youtu.be/w9k-L0GLLKM
• Our Journey Toward a Fully Backward-Compatible, UB-Safe, ISO C++ - John Lakos - https://youtu.be/whFzmXXhG5g

2026-09-28 - 2026-10-04

• Refactoring Towards Structured Concurrency - Roi Barkan - https://youtu.be/ttoQfPP_Gkg
• Design Patterns - The Most Common Misconceptions (3 of N) - Klaus Iglberger - https://youtu.be/bAsJvmtYZOg
• One Lib to Rule Them All and in the Darkness bindgen… - Antonello Palazzi & Kay Hicketts - https://youtu.be/9BpVjPKv02s

ADC

2026-10-19 - 2026-10-25

• Introducing LYDIA Phase2 - Kazuyoshi Sasamori, Alfie Bradic & Paul McCabe - https://youtu.be/MyCMBiWAEqM
• FPGA-Based Alias-Free Oscillator - 岡安啓幸 / Akiyuki Okayasu - https://youtu.be/OXB5crrpFgc
• Type-Erased Audio Parameters - A New Approach to an Old Problem - Jan Wilczek - https://youtu.be/K-38Zpf13lQ

2026-10-12 - 2026-10-18

• Introduction of the Technologies That Make Up Project LYDIA - Taichi Kumon & Tom Baker - https://youtu.be/-Cyht3g4H1s
• AI for Circuit Modeling - 村井 勝吾 / Shogo Murai - https://youtu.be/IL08vd0EiFY
• MIDI 2.0 - Ready to Ship - Brett g Porter - 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
• Hardware DSP Asset Inheritance and Evolution - Takeshi Kuwahara - https://youtu.be/yYukJpiFOOU
• Field Recording - In Search for Perfect Sounds - Malin Arvidsson - https://youtu.be/L5iZDi71VWU

2026-09-28 - 2026-10-04

• Designing Interactive Music Experiences in XR - Kasson Crooker - https://youtu.be/J3sVHT8luKs
• When (Not) to Patent Audio Software - Simon Hestermann - https://youtu.be/stBB1JoKQiY
• Distribution Strategies for Indie Audio Developers - From Plugin to Product - Dani Karanyi - https://youtu.be/Piar49uTjtg

Document #: P4433R0

Quotes:

It has come to our attention that during the DIS ballot, a small number of individuals have actively lobbied NBs against approving the C++26 DIS due to their own sustained opposition to contract assertions, a new language feature added in C++26. These lobbying activities have been accompanied by a public petition [Falco26] addressing NBs directly, a paper [P4334R0] that describes "fundamental flaws" in contract assertions, and other papers ² published around the same time by the same authors or a subset thereof.

The petition [Falco26] and the papers accompanying it contain a number of claims, including that C++26 contract assertions lack genuine consensus in WG21; that the design is hasty; that technical objections were not given a proper hearing; and/or that alternative designs were not considered. These claims are not true.

In addition, the description of C++26 contract assertions given in [P4334R0] contains a number of inaccuracies. It misrepresents the specification itself, ³ the amount of wording it consists of, ⁴ its design intent, ⁵ how it relates to hardening ⁶ and static analysis, ⁷ its existing implementations, ⁸ existing practice, ⁹ teachability, ¹⁰ and proposed extensions. ¹¹ None of the listed concerns are new; they have all been previously published by those authors (or a subset thereof), presented to WG21, and extensively discussed there. ¹²

Related post: https://www.reddit.com/r/cpp/comments/1xeeevt/balloting_has_completed_for_c26_unfortunately_it/

Note that I have no opinion on the topic myself. I'm just trying to understand what happened.

Since the C++26 DIS has been disapproved, the next step is going to be taken in Buzios during the 2026-11 meeting. The committee will have to decide what changes to make (if any) and submit an FDIS (Final Draft of International Standard) for Balloting.

In this paper it can be seen some interesting profiles progress for prototypes in Gcc and Clang.

A few months ago, I came across this article on this subreddit:

Four Ways to Dispatch a Runtime-Selected Strategy in C++

Most articles on this topic discuss dispatching methods in isolation, focusing heavily on the implementation details of a single approach. However, I wanted to see the bigger picture—not just pitting virtual functions against switch statements, but measuring the actual performance footprint of each strategy in real-world scenarios.

This benchmark does not claim to be academic or to represent absolute truth; I was simply curious to compare fundamentally different approaches. That is why I included not only standard comparisons like virtual functions vs. CRTP, but also deeply nested virtual calls that deliberately stress the instruction cache and branch predictor.

The project is still a work in progress. Living in Ukraine, frequent power outages caused by shelling have significantly limited my available development time.

AI Disclosure: Did I use AI for this project? Yes. Benchmarks starting from #12 were suggested by an LLM, which also helped refine the AVX2 search routine and proofread my English.

You can read about Eytzinger’s binary search here: https://algorithmica.org/en/eytzinger

The benchmark results are here: https://github.com/HarrierDuBoisX/Cpp-dispatch-benchmark/blob/main/result.md

You can find the code itself here: https://github.com/HarrierDuBoisX/Cpp-dispatch-benchmark

The introduction to StockholmCpp 0x41, with a few words from our host, news from international and national C++ standardization bodies, and, of course, the quiz!

I've been researching what "consensus" means in the C++ committee, and it seems there are two definitions that are similar, but I suspect result in different languages. In the first definition, you count hands on a poll, and if it clears the bar it moves forward. SD-4 says a proposal normally advances when more than twice as many are in favor as against:

https://isocpp.org/std/standing-documents/sd-4-wg21-practices-and-procedures

In the second definition, the chair looks for the largest piece of the design that nobody has a sustained objection to, moves that forward, and keeps working on the rest. (Disclosure: I'm involved in some of the contracts papers).

What is different with these definitions? A poll tally picks among the designs as written, so the one with the most hands wins, even if a third of the room is strongly against it. The second definition might pick something else, which is the biggest subset everyone can live with. For example, EWG forwarded contracts (P2900) at 25/17/0/3/12. That's 42 for, 15 against, and 12 of those strongly against. Under the first reading of consensus that's a clear pass. Under the second, the question becomes what part of it those 12 could accept, and whether the rest should wait. Am I wrong that these ship different things?

The culture of WG21 for as far back as I can tell has used the first definition. A poll count determines the design. There's another word that describes this: "Democracy."

The ISO wording seems to lean toward the second definition of consensus. Clause 2.5.7 defines consensus as "general agreement, characterized by the absence of sustained opposition to substantial issues by any important part of the concerned interests and by a process that involves seeking to take into account the views of all parties concerned and to reconcile any conflicting arguments."

https://www.iso.org/sites/directives/current/consolidated/

It says this "need not imply unanimity" and that sustained opposition "is not akin to a right to veto", so I don't read it as a one-person blockade. ISO's own guide for participants says "decisions within working groups are consistently reached through consensus, meaning there are no formal votes involved".

https://www.iso.org/files/live/sites/isoorg/files/store/en/PUB100037.pdf

Its convenor toolkit says the convenor "is responsible to determine when consensus is reached":

https://www.iso.org/files/live/sites/isoorg/files/store/en/PUB100416.pdf

I couldn't find a ratio for working groups anywhere in the Directives, and the 2:1 looks like a WG21 addition. Is a straw poll a "formal vote"? Maybe not, but is it consensus? Should it be?

Every ISO working group runs under that same text, so I'm curious how the other groups interpret it. I've heard secondhand that some deliberate the objections until they're resolved instead of counting. I can't verify that, and I'd love corrections from people who attend those other groups. The sibling group WG14 (C) publishes its minutes, and it uses straw polls too, so the answer clearly isn't simply "no polls". However, C does not seem to be evolving large features the way that WG21 does.

In March 2026, WG14 polled pieces of one proposal separately:

https://www.open-std.org/jtc1/sc22/WG14/www/docs/n3954.htm

A universal function pointer type got 21-2-2, the predefined macros got 6-9-6 against, and the integer typedefs got 10-2-11. That looks to me like finding the part people agree with, but I wasn't there and can't say for sure. If you're interested in the bigger picture, comparing how different ISO groups handle strong objections seems like a worthwhile research project.

Why might it matter more for C++? It's over 40 years old, and adding is easy while removing is nearly impossible. A committee paper called `vector<bool>` a mistake in 2007 and it's still there. Releases come every three years, so a deferred piece gets another shot soon, while a shipped one is permanent. The fair counterpoints are that the chair's call is hidden power, "the largest thing everyone accepts" could be watered down, and RFC7282 admits one intransigent person can "stop the process cold":

https://www.rfc-editor.org/rfc/rfc7282.html

The frequency of contested features is going up over time, as the committee grows in size and faces significant challenges such as memory safety and evolution (networking when?) In my opinion, if we use democracy to design C++, then there will be a growing divide between the winners of the vote and the losers of the vote, creating adverse social consequences.

Would it be better for the language if we prioritize general agreement over majority rule?

So I just wanted to vent about the absolute pain of making a working gui in cpp, I am working on a scientific project to make an openFOAM gui and browse openFOAM code to add TENO schemes to it from scientific papers such as Fu et al and working through the binaries.

I have not used AI in this project because CFD is very delicate and quite frankly, AI is not ready for such complexity - especially numerical schemes such as TENO, I ended up writing the meshing, topological code and mathematics myself and by far, the hardest part was the gui coordinates and memory management. I wanted to PULL MY HAIR OUT because of managing segfaults, crashes because of a random pointer hidden inside a 2000 line function, I had to also manage internal functions of openfoam(and you know how that goes), boundary conditions, and mesh topology, it was driving me nuts. I generally regard myself as fluent in programming languages such as cpp, python, rust etc, but this is a whole nother of level data management.

in the end it turned out to be a pretty good contribution to the openFOAM community, hopefully the project will mature further and I will be able to write a paper on it.

I feel like I have a pretty usual context, I have a couple of interdependent C++ projects that target various targets that primarily use cmake as their build system but various compilers. I work in a team of under 7 people and each of us has their own local machine and we also have configured a pipeline that configures/builds/tests the projects.

To minimize the differences between our local machines we reached out to providing containerized images as development environments per each target. This works ok from a reproducibility perspective however it always seems limiting and clucky to me. I'm always asking myself why wouldn't I try to use the native tooling on my machine and why wouldn't I use a package manager to provide me native tooling/dependencies?

In my mind something more similar to python's venv would be much more appropriate to encapsulate the development environment, right? I was looking for similar technologies and stumbled upon nix which has a downside of only running on unix systems(so no windows)... I'm curious how others are looking at this, because from my current perspective it seems that native environment encapsulation and sharing became too hard and containerization seems to be a sign of giving up managing our dev envs natively, am I wrong?

I still see the benefit of having containerized builds but it seems to me that the development environment should be provided by something else rather than being baked into a container image. I see containers as primarily a deployment technology and I feel that somewhere along the way we pushed it to be encapsulation of the whole development environment.

In coost, you can create coroutines using go in a way similar to Golang. The go function could initially be designed as:

cpp void go(void (*f)()); void go(void (*f)(void*), void* param);

However, this design only accepts two fixed function types and cannot support class member functions or other callable objects, making it insufficiently flexible.

If go were designed as:

cpp void go(const std::function<void()>&);

it would be more general, but constructing a std::function is relatively expensive, and its internal heap memory allocation is uncontrollable. This is unacceptable for coost, which pursues performance.

Therefore, to balance performance and usability, coost needs to implement its own closure class. In earlier versions, coost used an implementation based on virtual functions and inheritance, but it was not general enough and was limited to internal use.

Recently, I happened to have some free time. After thinking deeply about it, I redesigned the closure class. The design goals were as follows:

1. Do not use virtual functions or inheritance;
2. It should not be a template class;
3. sizeof(closure) == sizeof(void*), i.e. it contains only one ordinary pointer member, making it easy to pass to the coroutine scheduler through go;
4. Support arbitrary functions with no return value (including non-static member functions of classes), with any number of parameters;
5. Optimize simple no-argument functions such as void f() as much as possible to avoid dynamic memory allocation.

According to goals 2, 3, and 5 above, closure can initially be designed as:

```cpp struct closure { closure(void (f)()) noexcept : _p((void)f) {}

void* _p;

}; ```

The class contains only one pointer member _p. For function pointers of type void(*)(), the pointer is stored directly in _p; for other function types with parameters, a block of memory needs to be allocated to store the function address and parameters, and _p points to that memory.

The problem is how to distinguish which of the above cases is stored in closure. Ordinary function addresses are not necessarily 4-byte or 8-byte aligned, so tagged-pointer techniques cannot be used (i.e. writing a tag into the spare low bits of a pointer).

For the second kind of function, the one with parameters, closure calls co::alloc from coost's built-in memory allocator, and small memory blocks allocated by co::alloc are always 16-byte aligned. Therefore, if _p is not 16-byte aligned, it must store an ordinary no-argument function address. But if _p is 16-byte aligned, it is still impossible to distinguish the two cases.

It seems that some unconventional trick is required to solve this problem. Based on the discussion above, _p is either an ordinary no-argument function pointer or points to a dynamically allocated block of 16-byte aligned memory. If a specific marker (for example, a uint32 integer) is written at the beginning of that dynamically allocated memory, then when _p is 16-byte aligned, we only need to read the first 4 bytes of the memory pointed to by _p to determine the type of the closure. Even if _p is an ordinary no-argument function pointer and happens to be 16-byte aligned, reading the first 4 bytes of the memory it points to should be safe.

This of course goes beyond the scope of the C++ standard. But for performance and a better user experience, coost still adopted this approach. For functions with parameters, the corresponding constructor of closure is as follows:

```cpp template<typename F, typename = std::enable_if_t< !std::is_convertible_v<std::decay_t<F>, void()()>>, typename ... A> closure(F&& f, A&& ... a) { struct S { S(F&& f, A&& ... a) : _f(std::forward<F>(f)), _a(std::forward<A>(a)...) { static_assert(offsetof(Header, magic) == 0); _header.magic = 0xdeadbeef; _header.off = offsetof(Header, fp); _header.fp = [](void* p) { S const s = (S*) ((size_t)p & ~(size_t)1); if (((size_t)p & 1) == 0) { std::apply(s->_f, s->_a); } else { s->~S(); co::free(s, sizeof(S)); } }; }

    ~S() = default;

    struct Header {
        uint32 magic;
        uint32 off;
        void (*fp)(void*);
    } _header;
    std::decay_t<F> _f;
    std::tuple<std::decay_t<A>...> _a;
};

_p = co::alloc(sizeof(S), alignof(S));
runtime_assert(_p);
new (_p) S(std::forward<F>(f), std::forward<A>(a)...);

} ```

Key points:

• The !std::is_convertible_v in the template parameters ensures that simple lambda expressions such as [](){...} match the constructor for ordinary no-argument functions;
• _header.magic is always set to 0xdeadbeef, which is used to distinguish the type of closure;
• _header.fp is the type-erased function pointer, and its parameter p is the _p in closure. Here, a tagged-pointer trick is used to distinguish between "calling the function" and "destroying the closure object", thereby eliminating the need for an additional function pointer to store the destructor and saving memory.

The implementation of operator() is as follows:

cpp void operator()() { void* const p = _p; if (p) { if (((size_t)p & 15) != 0 || *(uint32*)p != 0xdeadbeef) { ((_F)p)(); } else { (*(_FP*)((char*)p + ((uint32*)p)[1]))(p); } } }

• If _p is not 16-byte aligned, or the first 4 bytes of the memory pointed to by _p are not 0xdeadbeef, then _p is cast to an ordinary no-argument function pointer and executed directly;
• Otherwise, the _header.fp described in the previous code is obtained according to the memory layout and executed.

An example usage of closure is as follows:

```cpp

include "co/print.h"

include "co/closure.h"

void f() { co::println("f()"); }

int main(int argc, char** argv) { co::closure c(f); c();

co::closure d([]() {
    co::println("[]() {}");
});
d();

co::closure e([](int v) {
    co::println("e called: ", v);
}, 8);
e();

return 0;

} ```

The complete code implementation can be found in co/closure.h. The code in this article is for research and reference only. Discussion is welcome.

Everyone is aware of the deluge of vulnerabilities now hitting critical software. It even makes the mainstream news, so software safety is coming onto politician's radars.

If this gets worse, I think it is not inconceivable that at some point memory safe software becomes mandatory. Or at least for software that is "reachable" from the internet.

So is it time to revisit Sean Baxter's Safe C++? Start out with a safe context ("safeexpr") and expand from there, just like constexpr.

An RC1 tarball for 3.28.0 is now available at https://sourceware.org/pub/valgrind/valgrind-3.28.0.RC1.tar.bz2
https://sourceware.org/pub/valgrind/valgrind-3.28.0.RC1.tar.bz2.asc

Public keys can be found at https://www.klomp.org/mark/gnupg-pub.txt

Please give it a try in configurations that are important for you and report any problems you have via our bug tracker at https://bugs.kde.org/enter_bug.cgi?product=valgrind

See the NEWS file for a list of changes and bugfixes https://sourceware.org/git/?p=valgrind.git;a=blob;f=NEWS;h=be8b91b474e71535f272e8f11f1f6d1d35826ed3;hb=HEAD

Unless showstopper bugs are found (and cannot be easily fixed) the final 3.28.0 release is scheduled for this Fri Oct 23.

Note that our mailinglists at sourceforge.net seem to currently be unavailable. Not a great time to have that problem...

My duckduckgo googling started giving me both, I don't understand the difference and don't remember which one is the original

They both look exactly the same
.com has en. at the beginning
.net doesn't have accounts

.net has the picture, .com doesn't

Is it a typosquash, is one of them fake, what's going on?

I keep hearing "modern C++." I've even used the term myself. And now I find I am questioning my use of the term.

1. What does "modern C++" really mean, specifically?
   
2. How many more years need to pass before it becomes just "C++?"
   
3. If "modern C++" is a thing then what is the other thing. Is it "old C++," or "legacy C++?"
   
4. Is C++ the only language that has a "modern" version?
   
5. If the answer to 4 is yes, why is C++ unique?
   

Qt Creator 21 - CMake Changes

C++Now

2026-10-12 - 2026-10-18

• Implementing Logic in C++ - Hans de Nivelle - https://youtu.be/3ffgtI31iKw
• The Secret to C++ Reflection Now: CMake Code Generation - Bret Brown - https://youtu.be/OW_h9oyHQ-0
• Co-Designing Integrated AI-Enabled Compiler-Runtime Systems - Hartmut Kaiser - 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
• Object Oriented Programming in Contemporary C++ - Steve Downey - https://youtu.be/m7gwSr27m74
• Cutting Some Slack for our Programs - Lisa Lippincott - 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
• SPL - Open Source, Constexpr Library for Composing Algorithms - John Bandela - https://youtu.be/96AGjm3uwko
• Senders For Existing Asynchronous Interfaces - Dietmar Kühl - https://youtu.be/KB5Nfofgu2k

ACCU

2026-10-12 - 2026-10-18

• Dependency Injection and Dependency Inversion - C++ Perspective - Vladimir Vishnevskii - 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
• The Not-So-Hidden Corners of C++ ABI Stability - Luis Caro Campos - 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
• Modernizing Legacy Codebases Without Stopping the World - Peter Muldoon - https://youtu.be/w9k-L0GLLKM
• Our Journey Toward a Fully Backward-Compatible, UB-Safe, ISO C++ - John Lakos - https://youtu.be/whFzmXXhG5g

2026-09-28 - 2026-10-04

• Refactoring Towards Structured Concurrency - Roi Barkan - https://youtu.be/ttoQfPP_Gkg
• Design Patterns - The Most Common Misconceptions (3 of N) - Klaus Iglberger - https://youtu.be/bAsJvmtYZOg
• One Lib to Rule Them All and in the Darkness bindgen… - Antonello Palazzi & Kay Hicketts - 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
• AI for Circuit Modeling - 村井 勝吾 / Shogo Murai - https://youtu.be/IL08vd0EiFY
• MIDI 2.0 - Ready to Ship - Brett g Porter - 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
• Hardware DSP Asset Inheritance and Evolution - Takeshi Kuwahara - https://youtu.be/yYukJpiFOOU
• Field Recording - In Search for Perfect Sounds - Malin Arvidsson - https://youtu.be/L5iZDi71VWU

2026-09-28 - 2026-10-04

• Designing Interactive Music Experiences in XR - Kasson Crooker - https://youtu.be/J3sVHT8luKs
• When (Not) to Patent Audio Software - Simon Hestermann - https://youtu.be/stBB1JoKQiY
• Distribution Strategies for Indie Audio Developers - From Plugin to Product - Dani Karanyi - https://youtu.be/Piar49uTjtg

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.