I’m aware that I’ve have been writing less lately, partly for work reasons and partly for conference reasons. Speaking of, let’s talk about ACCU on Sea 2026.

Bristol upon the Channel

It’s been a tough time for conferences and trainers alike lately. Deluded by the sirens of AI, companies have lowered their training budgets, convinced that a chat bot is as good as a teacher (or at least, “good enough”). While the market for C++ conferences (and I’m sure other domains too) had already got some trouble going back to in-person events following the pandemic, this clearly didn’t help. And so some conferences have chosen to merge together, as was the case for the long running ACCU and the more recent (in relative terms) Cpp On Sea.

They decided to go for the venue of Cpp on Sea in the town of Folkestone, on the Channel coast. Unlike Bristol it doesn’t have an airport you can fly to, but I’d consider this a minor loss given how bad BRS is at being an airport. Slightly more annoying is the fact that it’s set right next to the Eurotunnel but the Eurostar doesn’t stop there (it goes straight to London), making it a very silly trip from Paris when you look at your itinerary on Google Maps.

But more importantly, it’s not set at a all-in-one hotel + venue conference. Instead the conference uses its own event center (a rather nice if badly air-conditioned Victorian looking theatre), while attendees are spread out all around the small hotels in town. In my opinion it’s a big downgrade from the Bristol venue because being a hotel it came with its pre-designated hanging out spot after hours. In the absence of such a place, people spread out and clumsily try to find each other through Discord messages.

A new reader may discard this detail as the mere rambling a wine loving Frenchman, but I assure you I am not lamenting the lack of a primary after hour spot for a want of overpriced British imports (over £15 for some Australian nonsense? are you mad?). No, the reason I miss those venues is because that is where the most interesting stuff happens. That is where one can meet their peers, share stories and find inspiration, motivation or simply realize their problems are neither unique nor unsolvable (see the Unicorn Syndrome). And while I still got some of that this year, I can’t say I got nearly as much as last year on that front.

Are we AI yet?

Let’s get the clanker part out of the way. Yes this year again they had 2 keynotes about AI. Yes they again were neutral-to-bullish on AI. I will admit this is an improvement upon last year where the 2 keynotes on AI felt like paid product placement, but I still see it as a refusal to engage critically with the topic. I could tell from the audience questions, especially during the second one (Out of Our Minds: What is AI Doing To Us and For Us?) that there is still a lot of reluctance (if not outright refusal) to take the promises of the AI Eldorado at face value.

I suspect this is possibly because no one who is unconvinced by AI will bother writing and submitting a talk about their thoughts on the topic, but for keynote speakers who are usually invited and given somewhat carte blanche on the abstract, it should be possible to find someone who has something more interesting to say about it. To be honest I could believe that Andrei Alexandrescu’s opening keynote was trying to offering a broader perspective on engineering in the age of LLMs, but it’s hard to take a NVIDIA corporate slide deck at face value when it comes to AI, at this point it’s not even a conflict of interest for them, it’s life or death given how much their valuation is tied to the dream of everyone paying for AI GPU compute forever.

Safety Third

A big topic of the past couple C++ seasons has been safety. If you haven’t followed the committee news, the past US administration published a report on tech with a section that was basically summarized as “the government will stop buying anything written in languages that aren’t memory-safe” and a lot of people panicked. If, like me, you’re more attached to the games industry you might not care much for it, but trust me when I say there is a lot of money at stake when something as big as the US government starts saying “we won’t buy stuff written in C or C++ anymore”.

That original report has since been eaten by the subsequent administration (it’s not available on official sources anymore) but the worry is still there. This was further exacerbated by recent research that found that some LLMs could be used to find exploits in programs that invoke undefined behaviour.

And so, ACCU On Sea offered a selection of talks on the topic of what has been and might be done in the future to improve the safety of C++ program, meaning detecting and preventing the use of undefined behaviour.

The main thing that recently landed in the C++ standard on that front is contracts. This year we had a talk by one of its original authors, John Lakos. In Our Journey Toward a Fully Backward-Compatible, UB-Safe, ISO C++ he argued that the ability to selectively turn contract assertions on in production would guarantee that over time all instances of UB are found. While his suggestion of toggling on and off selective assertions on a rotating subset of production machines is a good way to use the power of statistics to catch bugs for much less impact than switching it all to debug builds, I think the entire proposition fails on a simple premise:

You cannot test for the most common case of UB (lifetime issues) in an assert.

There is no assert(std::is_valid_lifetime(ptr)). Technically speaking, you could possibly do what ASAN does by instrumenting every C++ construct that starts and ends an object lifetime and then provide an API that does the equivalent check¹ but that’s not native to the language.

And even if it could be done, we have had assert since C89 and yet the industry still chose to create Rust. We have been able to write a custom assert macro with a handler that could be configured at runtime for as long as I’ve lived. If that was a serious way to make a safe program, I’m sure we’d all be doing it by now. One may counter argue that this hasn’t happened because of a mindset issue, but the fact remains that the tech for contracts has been around for longer than C++ in some form or another. While it is nice to see it formulated as a language construct that can be seen and used by compilers and sanitizers alike, I sincerely doubt that this is the silver bullet that will turn C++ programs safe.

Rust and Friends

One alternative solution that was brought up in several talks (including One lib to rule them all and in the darkness bindgen… and Incrementally securing your C++ using Rust) is to build upon Rust interop. Since there’s a lot C++ out there that can’t be magically translated to Rust², it makes sense to have a binding layer between both languages so that new projects can be written in safer languages while still leveraging the decades of engineering that are already there.

The classic way is what you might expect if you ever had to do language interop: go back to C ABI and pass C structs and void * along on both sides. The portable solution to automate at least part of the glue is to use things like bindgen (as the eponymous talk above explained). The closing keynote showed us an alternative that works closer to C++, if and only if you live in the Google world (Bazel, clang/llvm only, etc…). The tech they showcased seems able to directly translate safe C++ types into Rust and vice-versa, including containers, owning pointers and spans, but only if you use libc++ and clang (they have a CMake version in the pipes for most of us who don’t use Bazel). It’s technically possible to extend it to support GCC, libstdc++ and even MSVC, but it hasn’t been done yet (and probably won’t be done by Google as they don’t need it).

Speaking of compilers, now is a good time to mention that word on the street is that Microsoft seems to have dropped the ball on C++ (and apparently not just C++). Their compiler/language team is clearly underfunded, as shown by the very slow adoption of C++26 MSVC is currently showing compared to C++20 and even C++23 where they were trying to be the best in the classroom. The whole vibe I got from talking to people is that I should be looking more closely at clang-cl to hedge my bets. Hopefully Microsoft will one day roll back their decisions to divest from engineering (right now they seem to be putting all their thoughts and budgets into AI), but who knows when that might happen.

To conclude with the safety part, I want to mention that I really like Jon Bauman’s The Future of C++ Is Memory Safe talk where he explained his journey from looking at interop from the Rust side to making proposals to the C++ standard. His paper seems to have been well received and unlike what I heard from alternative proposals (such as Profiles), he seems to have a concrete grasp on what needs to be added to C++ to get on par with safety. Spoiler warning: pointers and references need to carry more metadata in order to implement a safe subset of C++ with compile-time lifetime checks similar to Rust’s borrow checker.

Now of course, this entirely rests on the committee’s ability to actually get the thing done and accept the cost. In the past polls asking “do we want C++ to do X” have done very well, but then got stuck in limbo when it was time to pay the bill and accept a potentially costly breaking change. You might remember how Google basically gave up on the C++ standard after the refusal of the committee to commit on a decision about performance when it came down to concrete impacts on ABI at the 2020 Prague meeting³.

Other Topics

I enjoyed watching The Async Pattern Graveyard which explained a lot of how the Boost ASIO experience lead us to Senders and Receivers as they are today. I could clearly tell that is the culmination of 20 years of homework on how to do async without weird edge cases and unnecessary allocations that have been found through practical use.

Sadly it also comforted me in my opinion that parallelism and related practical implementations are still seen as an afterthought. This is really about the core abstraction for connecting async tasks. If like me you wonder if this is finally when we get to have a good work stealing thread pool in the standard library, the answer is still no. That part is clearly viewed as an implementation detail by the execution framework. As I mentioned last year, TBB still isn’t going anywhere.

Finally, on lower level topics, I quite liked Matt Godbolt’s Microarchitecture: What Lies Beneath which explained how modern Intel x86 CPUs work behind the assembly language they present, all thanks to a lot of reverse engineering done by various people over the years.

I also heard great things about Processor Design and Memory Models but sadly couldn’t attend it due to scheduling conflicts. I’m looking forward to the uploads on Youtube.

Final Thoughts

It was, as usual, an enjoyable conference and I think the team managed to make the best of a situation that forced them to merge two different events into one. There’s stuff that could be improved with the venue, I didn’t mention how underwhelming the food was (lunch was quite repetitive and very heavy on carbs and while breakfast and other breaks came with nothing to eat), and how the disparity of room sizes had people standing in some talks while other rooms were half empty. I’m sure they’ll be looking into that.

Still, I hope to see you all next year again!

¹: That will likely get you false positives because a bunch of idioms inherited from C like casting a void * (or a byte*) to a real type does not start a lifetime prior to C++20 and so accessing the returned pointer is technically UB, but also a thing we’ve been doing for 50 years. See C++23 std::start_lifetime_as.

²: Interestingly I didn’t hear of any real success asking Claude to rewrite a C++ project in Rust and make no mistakes. No that guy who merged a 1 million lines commit that rewrote his Zig project into Rust doesn’t count.

³: Google brought a paper asking them to chose between performance and ABI stability because quite a few proposals have been shot down (and continue to be shot down) because they would require compilers to break backward binary compatibility. They refused to pick either, saying they totally wanted performance and also would accept breaking ABI “in future release”, but just never the upcoming one. A future hypothetical one when the stars align. This lead Google to give up on trying to change the standard and instead focus on what they can do with extensions to their own toolchain (clang/llvm) only.