ACCU on Sea 2026 Trip Report by MARGO: Modern C++ Insights for Systems Engineering

---

Focus 1: structured concurrency & modern asynchrony at ACCU on Sea

One of the major topics of this 2026 edition of ACCU was the formalization of structured concurrency and the announced end of legacy asynchronous models. Asynchrony in C++ has a complex history, marked by abstractions that are often inefficient or prone to errors. The dedicated sessions allowed for an assessment of this history to better understand the breakthrough brought by the Sender/Receiver pattern planned for C++26.

The “graveyard” of legacy asynchronous patterns

Robert Leahy’s session (The Async Pattern Graveyard) highlighted the architectural flaws of historical approaches:

• C-inherited approaches: the function getaddrinfo is blocking, which is why the C library ares offers an asynchronous alternative ares_getaddrinfo. Although asynchronous, this C function relies on a callback and channel system for error handling, making its use complex. It suffers from the limitations of the C language for the asynchronous pattern.
• Native STL abstractions: the classic use of std::future and std::async is today considered outdated (graveyard material). These models suffer from implicit and systematic heap allocations, the absence of native task dependency management, and a rigid execution model.
• Comparison with Boost.Asio: although Boost.Asio is widely used in production, the raw callbacks model remains complex to maintain and particularly error-prone compared to the new standards based on RAII.

The advent of std::execution (Sender/Receiver)

The modern paradigm now relies on the Sender/Receiver pattern defined in std::execution. Its fundamental principle is to totally decouple the definition of work from its actual execution context (the thread or thread pool that will execute it).

Feedback: from live coding to production

Two key sessions allowed this theoretical framework to be confronted with the reality of the field:

• Practical implementation (Dietmar Kühl): through the live coding of an asynchronous network interface communicating with a PostgreSQL database, Dietmar Kühl demonstrated a complete and real use case of this new framework. However, the exercise revealed the current complexity of implementation, raising numerous discussions on the volume of necessary boilerplate code to write one’s own custom Sender. The design of a sender turns out to be very user-oriented, as it directly shapes the writing of the algorithm that depends on it.
• Refactoring and algorithmic locality (Roi Barkan): the session Refactoring Towards Structured Concurrency highlighted the transition from legacy architectures to structured concurrency. The main advantage lies in the ease of injecting dependencies into asynchronous tasks and in strict compliance with the RAII nature. This pattern brings better locality to our multithreaded algorithms, which greatly facilitates reasoning about the code and the overall design of concurrent systems.

Point of vigilance: the impact on performance

Despite these major advances in terms of design, the topic of performance remains the current critical point of the Sender/Receiver pattern. At this stage, efforts still need to be made:

• On the compiler side: regarding the optimization of code generated from the different sender scenarios.
• On the scheduler side: regarding the need to write customized and optimized schedulers to maximize real performance gains compared to existing solutions.

---

Focus 2: summary on metaprogramming and C++26

The introduction of standardized reflection constitutes one of the most eagerly awaited and powerful projects of upcoming C++ standards. Exchanges at ACCU 2026 allowed a clear vision to be drawn: if these features offer unprecedented abstraction capabilities, their implementation in production requires extreme vigilance in the face of compiler realities.

The macro vision: specialization and verbalizable abstractions

Andrei Alexandrescu’s opening Keynote (The Next 20 Weeks of Systems Engineering) set the macroeconomic and technical framework for these evolutions. According to him, the impact of AI inevitably pushes towards the specialization of expertise, because generalist work on superficial layers can now be easily automated. To sustain codebases, systems must verbalize themselves through clear and common abstractions. This is precisely where the new features of the language come into play:

• Contracts: to provide clear usage obligations.
• Reflection: to abstract and reason about the code itself.
• STL hardening: to secure programs by eliminating Undefined Behaviors.

Bridge-building: from compile-time to runtime reflection

By definition, native C++26 reflection operates strictly at compile-time. However, real software engineering (gRPC serialization, dynamic object mapping, UI bindings) often requires runtime flexibility.

Laurie Kirk’s presentation introduced CMM (Call Me Maybe), a library designed to build a bridge between these two worlds. CMM addresses the challenge of transitioning consteval values to static values at runtime. Its strength lies in its total lack of reliance on RTTI (Run-Time Type Information). By using lightweight annotations and leveraging new features in C++26 — particularly define_static_objects and consteval blocks —, CMM allows for runtime reflection that outperforms legacy libraries while minimizing the impact on binary size (binary bloat).

At the same time, Hana Dusíková’s session (Where does constexpr start and where it ends) assessed the current state of compile-time. She detailed how the compiler behaves like a true C++ interpreter executing code during the compilation phase. To conclude, Hana insisted on the constant effort of making everything that can be constexpr in the standard. It was a message to all proposal authors for the standard: compile-time should not be an option. As a bonus, she presented the power of her favorite data structure: the hashed Array Mapped Trie (HAMT), which guarantees high performance for lookup, insertion, and deletion.

The reality of compilers: the nightmare of IFNDR

---

Focus 3: microarchitecture, memory models & hardware

Optimizing performance in C++ cannot be achieved without a fine understanding of processor microarchitecture. At this level of engineering, theoretical algorithmic complexity often fades before the physical reality of cache management and instruction execution by the CPU.

CPU Pipeline and Out-of-Order Execution (OoOE)

Ofek Shilon’s session (Processor Design and Memory Models) detailed how modern processors execute instructions and maintain an up-to-date view of the content of their caches. To maximize efficiency, CPUs execute instructions in an order different from that of the source code (Out-of-Order Execution) thanks to specific hardware components:

• The Register Alias Table (RAT): which manages register renaming to eliminate false data dependencies.
• The Reorder Buffer (ROB): which guarantees that, despite out-of-order execution, instructions are retired and applied in the correct original order.

However, this sophisticated mechanics is accompanied by strict constraints when handling atomic operations or multithreaded code. The CPU pipelines and the exact moments when atomic instructions come into play condition the efficiency of the program. Improper use of atomics can block these hardware mechanisms, causing significant drops in performance.

Branch prediction and cache management

Matt Godbolt, during his session Microarchitecture: What Lies Beneath, went even further into the reverse engineering of CPU firmware to understand the use of internal tables and caching.

One of the major lessons is the critical cost associated with branch prediction. Disrupting branch prediction — or invalidating it completely — destroys performance. For example, the phenomenon of False Sharing forces the CPU to invalidate everything it has cached in order to synchronize cores, which loses all the benefit of hardware predictions.

A direct discussion with Matt Godbolt also shed light on optimization via PGO (Profile-Guided Optimization). It turns out to be very difficult to set up PGO effectively in simple contexts. Our compilers and processors have become so powerful that the base case and natural branch prediction are often closer to the actual execution time (runtime) than what we try to predict with PGO. For PGO to bring a real gain, you must find yourself in situations where the mass of executed code exceeds what the CPU can keep in cache, a complex scenario to design.

Synchronization primitives and Memory Models

---

Focus 4: our experts’ synthesis on Legacy management

The final part of ACCU 2026 focused on the frontier between the promises of the language and the reality of their execution, as well as on the industrial tooling necessary to evolve existing code without introducing regressions.

The illusion of “Zero-Cost Abstractions”

Steve Sorkin’s session (When Zero-Cost Abstractions Aren’t Zero-Cost) challenged a received idea in C++. In theory, a zero-cost abstraction must induce no loss of performance at runtime. In practice, the compiler can experience difficulties in optimizing certain syntaxes that are nevertheless very clear, such as std::views or STL ranges.

Steve Sorkin illustrated this problem by analyzing the generated assembly code. For example, chaining several filters interspersed with a transformation (filter | transform | filter) strongly perturbs the compiler. Instead of fusing the operations, the compiler generates code that traverses the chain multiple times, which generates a significant machine cost compared to a classic loop. The conclusion is clear: to validate an abstraction, studying the assembly and taking field measurements remain indispensable.

Dangers of optimizations and Undefined Behaviors (UB)

Robert C. Seacord (C committee member) demonstrated how aggressive compiler optimizations can prove destructive when they collide with Undefined Behaviors.

The textbook case presented concerned the automatic removal of null pointer checks. If a pointer is dereferenced at the beginning of a function, the compiler assumes that this pointer is valid. Consequently, it purely and simply deletes all safety tests if (ptr == nullptr) located further down in the function. If the initial dereference does not crash the program, the safeguard disappears before the compiler (a pitfall that notably affected the Linux kernel). The recommendation is to systematically enable compiler warnings.

Industrial Modernization of Legacy: LLM vs Scripts

Peter Muldoon’s session (Modernizing Legacy Codebases without Stopping the World) brought a very pragmatic perspective on managing legacy code on a large scale. Modernizing a massive codebase cannot be done magically or entirely automated via LLMs or exclusively clang-tidy.

The effective solution consisted in making these two approaches work hand in hand. The LLM was used to generate deterministic automation scripts. This method presents several advantages:

• Reliability: it frees the process from the non-deterministic nature and hallucinations of LLMs.
• Auditability: a script is a piece of code about which an engineer can reason, test, and validate on a specific case.
• Industrialization: scripts allow the project to be broken down into distinct code reviews (PR/Commits), facilitating collective contribution and project tracking.

Alongside these methodologies, Tim Condon’s session (Incrementally migrating C++ to a memory safe language) highlighted that other languages are striving to design robust bridges with C++ to guarantee better interoperability.

---