ACCU on Sea 2026 Trip Report

ACCU on Sea is a love child of two long-running ACCU conferences and C++ on Sea. It dedicated four full days of talks to C++, Rust, hardware and engineering practices. And it is happening at sea!

I’ve never been to the original ACCU, but heard a lot of kind words about it. It definitely has more academic roots than other engineering conferences. They publish periodic journals with peer-reviewed articles, giving me old feelings about WIRED, RSDN Magazine and scientific journals. Topics are more abstract, covering not only C++ (the second C in ACCU), but also generic development topics.

C++ on Sea, on the other hand, is more on the pure C++ engineering side. Scientists are welcome, but you don’t need a PhD to listen and participate in a lively discussion.

This year they joined together, following an unfortunate trend in which companies spend their money firing people in favour of tokens rather than sending them to conferences to learn and bring back fresh knowledge.

I attended C++ on Sea last year, and ACCU on Sea this year, as well as a few other conferences across Europe and the UK. I should say that it was a very nice, open and engaging place to be, to discuss ideas with attendees and, of course, to listen to the talks.

Keynote - The Next 20 Weeks of Systems Engineering

Andrei Alexandrescu opened the conference with a philosophical talk about the development and value of abstractions. When you no longer write code (I do, since it’s the only fun in development), how should you tackle code design and use proper abstractions? Andrei questioned the cost of abstractions — “Features are useful in proportion to added abstraction”, and that’s particularly true. Contracts abstract intention, and C++26 reflection abstracts the code itself. I am worried about C++ going down the road of Ruby and Scala, with an overcomplicated, vague language and library ecosystem. Having too many abstractions tempts developers to add layer upon layer of them. But they are useful in the AI era, since LLMs can operate faster and better with high-level abstractions when code has a limited scope and size. Actually, the same applies to a developer, but developers are paid a flat rate, while bloated context for AIs costs you a fortune. Zero mentions of D throughout the talk, by the way.

Portable Reflection in C++26

Then I started a series of talks on reflection. As Hana noted, it’s an entirely new language. A sweet dream of metaprogrammers since Alexandrescu’s first book, an object of envy for people looking at the JVM and scriptable languages. Now it landed in the C++26 standard (and in your company’s approved compiler in a few years).

Dan is one of the masterminds behind the reflection work in the standard. He presented a “Portable Reflection” talk on proper, well-defined ways to build a working C++ program using reflection. I’d better call this talk “Reflection on IFNDR” — Dan explained how severe this problem is for your naive C++ program with new reflection features. If you are afraid of UB, you should be scared of a much worse case of it — IFNDR (Ill-Formed No Diagnostic Required). A program with IFNDR can be compiled, but it is fundamentally broken. There is no legitimate way to distinguish it from a valid program, since the compiler is no longer obliged to follow any C++ rules. In contrast to UB, where bad behaviour can be isolated and sometimes even never hit, IFNDR means the whole program is utterly broken. A famous example by Raymond Chen is the ODR violation:

// file1.cpp
inline int magic() { return 42; }
int get_value() { return magic(); }

// file2.cpp
extern int get_value();
inline int magic() { return 99; }

int main(int argc, char** argv) { return get_value(); }

Reflection gives you many more possibilities to make IFNDR. Say, when you reflect on the contents of a namespace declared before and after a call site, the results can be completely different. Dan followed up with smart ideas for overcoming it. I highly recommend watching this talk as a detective story. It’s a good start towards gathering best practices for metaprogramming, which are currently lacking.

CallMeMaybe: Building Modern Runtime Reflection via C++26

Laurie Kirk (the famous hardware and security blogger) explored a different aspect of reflection. What if we want to build a runtime reflection system based on compile-time reflection? Yes, with the help of her CMM, you’ll be able to iterate over types, create objects, and call methods. The idea is to build a runtime registry of entities, gathered at compile time by walking the type system via reflection. The bridge between compile- and run-time is the thunk, providing a low-level invocation mechanism via void* with really low overhead. A complicated part of the design was the necessity of building a parallel type system to std::meta. Aside from this, the concept of the library is really surprising and elegant. Kudos to Laurie.

ABI and UB

Moving to more undefined areas. A talk Dangerous Optimizations! Part Deux by Robert C. Seacord in defence of undefined behaviour and compiler optimisations. The speaker has a good point that UB gives compilers freedom to emit more performant code and apply optimisations. Robert talked about the long decade when compiler vendors adopted a pure performance approach, with aggressive instruction reordering, dropping null checks, misinterpreting aliasing rules, and many other non-obvious ways to make a program behave unpredictably. A solid piece of advice from him is to use compile-time checks (warnings and analysers) and runtime checks (sanitisers and fuzzers). I am sure it’s a bare minimum for any program. Given the number of problems UB caused people, the cost of having an evil UB is higher than the cost of a performance win. Contracts are moving C++ in the right direction, since you can control the level of their checks. And it’s not only a compiler: C++ libraries tend to have undefined behaviour as well — remember the famous glibc change where memcpy ignored aliasing rules. The session mostly leaned towards C practices, so unfortunately I haven’t heard about C++-specific aspects — and there are many.

Luis Caro Campos, one of the people behind the Conan package manager, shared more stories about ABI stability. A lot of curious facts about ABI, dealing with core dependencies like glibc/runtime, OpenSSL, zlib and other pretty fragile libraries. I worked on Conan packaging for a while, and trust me — it’s a huge challenge. The talk itself is not purely Conan-specific, so take a look if you’re interested in ABI and cross-platform builds.

One lib to rule them all and in the darkness bindgen…

Yes, that ring.

Kay and Antonello were talking about a multi-language API and how painful it is to write bindings when you don’t have a stable or compatible ABI. Going back and forth from Rust to a C++ binary is not an easy ride, much harder than going through Middle-earth. They explained many obstacles, such as memory layout, call conventions, different memory ownership models in C++ and Rust, and the very different meaning of callbacks. A giveaway: don’t build a false intuition about the similar syntax of structs, since they have entirely different layout and ABI guarantees.

The speakers decided to abandon the C++ API altogether and descend to Moria the C API. It is a good idea when the API is simple, well-designed and resembles best practices of UNIX. Then bindgen shines. The downside of this approach is having C++ in the loop. Writing a C API for C++ types is tiresome and sometimes impossible. Also, marshalling types between C and C++ could be quite costly. Imagine a std::vector<std::string> — what is the best equivalent in a C API? What about a map or nested data structures?

It brings us to the keynote talk by Taylor Cramer —

Incrementally securing your C++ using Rust

Google surely has one of the largest C++ codebases and cares about memory safety more than ever. Hence, using bindgen, older cxx, or manual bindings for interop is almost impossible at scale. So they invented crubit — a tool that creates pure Rust bindings from C++ files via a CMake harness (corrosion-based), supporting Clang only so far. There is no need for IDL. C++ types are nicely mapped; enums and strings are first-class citizens; traits become templated structs with compile-time dispatch… function overloads are… well, mostly welcome in Rust. Crubit is actively being developed and is awaiting users outside Google. I’m thrilled to give it a try! Taylor Cramer delivered a great, entertaining, and optimistic keynote, showing that working hard on a serious problem can yield unexpectedly strong results.

The Future of C++ Is Memory Safe

To conclude the safety series, I attended a slightly sad story from Jon Bauman about his journey with the C++ committee, the Rust Foundation, and a bold idea to make C++ a safer place. While I expected more technical content, I enjoyed this talk much more because it was about communicating with people, setting goals and taking a philosophical approach to software development.

Microarchitecture: What Lies Beneath

A classic Matt Godbolt talk about low-level programming and hardware. A processor just sits in front of you, and you have tunnel microscopes and a pile of Intel Developer Manuals, but how does it actually work? Nobody knows, except Intel and a few hardware enthusiasts armed with microbenchmarks and disassemblers. This time, Matt spoke about the microarchitecture of Skylake, explaining in detail instruction decoders, register alias tables, and how they affect compilers and developers. A very interesting talk for everybody working with CPUs, GPUs, microcontrollers or any other silicon-based hardware life form.

“Serial C++ can be parallel too”

Another hardware talk was about SIMD and how std::simd enables it for developers without resorting to assembly or intrinsics. Interesting talk, and a good delivery of a highly complicated topic. I am more than aware of this problem — how hard it is to make hardware abstractions work flawlessly for a high-level language (I even presented on a similar problem in the Rust standard library) — and still found this talk useful.

constexpr Queen

A great talk from Hana Dusíková. As usual, she explored the state of the constexpr ecosystem with a quiz: “Are we constexpr yet?” Hana explained not-so-obvious aspects of it, such as evaluations and memory allocation in constexpr. If you don’t ponder it much, things just work automagically. Essentially, constexpr adds another target architecture for a compiler: it must interpret and execute constexpr code against the AST and provide results back to the compile-time universe. It’s a tremendous amount of engineering work.

The second part of her talk is slightly unrelated to constexpr — a tour of a modern data structure called HAMT (Hash Array Mapped Trie), popular in functional languages. It is similar to a hash tree, a mix of a hash table with a search tree, but without rehashing and much more memory-efficient. Hana also demonstrated how it could be used in an append-only manner for update operations, where only the affected HAMT node is appended to the underlying buffer, making it concurrency-friendly in the style of LSM trees. Check this out, I enjoyed the delivery and diagrams very much.

Senders For Existing Asynchronous Interfaces

A hardcore coding session “Senders For Existing Asynchronous Interfaces” from Dietmar Kühl about coroutines and sender/receiver primitives built upon them — a continuation of his CppCon The Sender/Receiver Framework work. A highly professional developer, Dietmar literally wrote a large part of a framework in one hour — a pleasure to watch, open-mouthed and with a bag of popcorn. Unfortunately, C++’s async support is so spartan that you have to write all the required components from scratch. So everybody does. Dietmar’s kuhllib has good implementations of async primitives. It clearly indicates how crucial it is to have building blocks somewhere — in std, Boost, abseil, BDE, or wherever. Now, it’s the Wild West, and I’d better write an async program in Rust’s Tokio or Python’s asyncio, and abandon C++ async until better times. This is a sad state of C++ asynchronous programming.

Conclusion

As you can see, the recurring topics were language enforcement, reflection, memory safety, and one other well-known language. The programme was good, but room allocation could have been better — of course, one cannot predict attendance. Given the conference took place in a beautiful Victorian hall on Kent beach (just days before a UK heatwave), it became slightly uncomfortable. I’d appreciate more cold drinks and fans. I enjoyed the after-parties and the community’s openness, and it was truly great to meet everyone there. ACCU on Sea is a great conference to attend, whether you’re travelling from the UK, Europe or even the Americas. See you all next time!