Other talks and panels of note

You Shall Not Pass*!

CppCon 2026: You Shall Not Pass*!

This was almost definitely my favourite talk. It is all about how you can architect your project to minimize having to deal with raw pointers. I am quite biased because the topic is something I am quite interested in and have written a blog on the subject Pointer Parameter Problem – Clever Programming Pun.

Daniel Pfeifer’s idea is that owner and reference semantics should be implementation details of a greater concept rather than the things we deal with in our business logic. He grounded this in Sean Parent’s No Raw Loops rule. Except he wanted to move the conversation to “No Raw Pointers”. A raw pointer is any pointer, smart or not. A pointer is something with ownership and reference semantics. Once you start passing these around all of your local reasoning goes out the window and you need to care about where that pointer came from and what its lifetime is.

Again this is something that I talk about quite a bit in both my main talk, and in my lightning talk of this year. It is something I care a lot about, and hearing Daniel talking about it was like music to my ears.

So how does Daniel propose getting away with not passing pointers around? By creating classes which behave as containers and use owning pointers as the implementation. So you pass around objects of these containers, rather than the underlying pointers. It’s like favouring a std::chrono::seconds for a delta time rather than a float. You are baking the meaning of the value into the type, rather than relying on convention. I love this stuff

A large amount of the talk was taking us through implementing a class which was like a std::vector that holds one element. Or I guess another way to look at it would be a std::unique_ptr that allows copying. So essentially a dynamically allocated object that you can just pass around. The first implementation is what you might write if you want to implement everything yourself, but there is a lot of boilerplate as a result. He then simplified the implementation step by step by using some nice standard library facilities:

1. std::unique_ptr -> gets rid of a lot of the ownership semantics, but it still meant that you would have to implement the copy operations
2. std::indirect -> essentially a std::unique_ptr that will do a deep copy. Nice! But doesn’t handle polymorphism
3. std::polymorphic -> essentially a std::indirect but also handles polymorphism

He also talked about the proposed std::copy_on_write which is a container that uses reference counting to copy, so it is like a shared_ptr for standard copy operations. BUT as soon as a “copy” is modified, then an actual deep copy happens and produces an entirely separate object with a separate reference count. This is effectively how some standard libraries implemented std::string up until C++11. It’s a pretty nice utility that makes copies cheap provided that copies only read the data rather than write to it.

All in all, this was an exceptionally good talk with many applications to the way that we design software. Loved it.

Mock any Function in C++ Without Changing a Single Line of Code

This is almost the opposite end of the spectrum from “You Shall Not Pass*!” for me, but still something that I think is worth watching… in horror.

The premise is that dependency injection is too great of a sledgehammer to make your code testable.

They also talked about “link-seam mocking” which basically means that you keep your real and test implementations in different libraries, and you link the test library for tests, and the real implementation for production. It was mentioned that both “link-seam” testing and dependency injection don’t scale well.

As an aside, it seemed like the speakers were coming from the perspective of having a mature project already, and they want to make it testable after the point of release. So testability wasn’t thought about when the project was being developed. This to me sounds like the real problem. It also explains the middle point in the slide above. You don’t typically introduce dependency injection after the fact, just for the sake of testing…

So, you have an untestable behemoth of a project and you suddenly want to invest in actually writing tests for it. How do you do it? Through fascinating and horrible hacks! The library that they are talking about can be found here bloomberg/bonobomock. Why is it called “Bonobomock”? Because it uses a thing called “Monkey patching” to mock functions.

What is Monkey Patching? Essentially you give the library the function you want to mock as a function pointer. That function pointer points to the instructions of the function in memory… So they save the initial instructions, then overwrite them with a jmp to the mock implementation. So when the actual function is called (and it doesn’t matter where from. This modification is process wide), the first thing that happens after setting up the registers with your arguments is that you jump to your mock function, and everything continues from there. On destruction of the mock object they restore the original instructions. I will admit that it is cool and it is the sort of thing that would make me giggle if I wrote something like this and got it to work, but… holy undefined behaviour batman!!

The talk just kept getting more cursed from there:

1. For member functions, you can specify that the mocked implementation should be used for all objects or just for specific objects. The library will basically look at the this pointer that called the function to determine what implementation to use.
2. For private and protected members, they essentially stringify the name, and then look through the PDB to find the address of the function code.
3. Small functions are fun. Functions can be less than 14 bytes (the size of a jump to anywhere in virtual address space), so they use a small jump of 5 bytes. This can jump anywhere in memory that is +-2GB from the function to mock. So if the mock implementation is within 2GB, happy days, it just jumps straight there. If it is not within 2GB, they find a free page that is + -2GB from the function using something like VirtualAlloc, then put a trampoline at the found location to jump them safely to the mock implementation. What happens if the function is less than 5 bytes in size? Tough. You are overwriting 5 bytes regardless. What happens if the mock implementation is further than 2GB away? Tough. You are overwriting 14 bytes. So this can absolutely corrupt your binary. FUN!

Then they talked about all the hoops they have to jump through to even get this to work.

• They have to make sure that they flush the instruction cache after writing the modified instructions, before execution resumes, so that threads will actually see the modification
• They have to be aware of calling convention
• They have to turn off inlining… because technically the function doesn’t exist for inlined functions
• And I am sure more stuff that I missed

Everything presented here is really cool, but it genuinely sounds like a nightmare to maintain for various configurations, hardware, and compilers.

Processor Design and C++ Memory Models

ACCU Link: Processor Design and Memory Models - Ofek Shilon - ACCU 2026

This was a great talk and I think it would be beneficial for most engineers to give it a listen. I missed it at ACCU on Sea this year, and Matt Godbolt had some really good things to say about it, so I made sure to catch it at CppCon. It is VERY low level, and covers fairly advanced topics. It certainly was not a talk for beginners. But there were some great insights in it. I mentioned above about how Bonobo mock had to be careful about instruction caches when it was performing its horrors. This talk answers why that is the case.

Ofek mainly talked about how C++’s memory model tries to match that of general hardware memory models. Some interesting points that were made:

1. The hardware will bend over backwards to avoid touching memory. So when you “write to memory” you are typically writing to the cache, and your core’s cache will do “Cache Forwarding” to forward that write to the cache on other cores using invalidation queues. The main reason for the CPU to write back to main memory is when a cache line is evicted. It makes sense because of how slow memory is, but I don’t think I ever knew the extent of all the tricks that are done to avoid writing to it.
2. Writes can be coalesced if they will hit the same cache line. Makes sense because memory is read and written from cache lines

The last part of the talk concerned how all of the talk about memory hierarchies and caching mechanisms can be worked with in C++ using std::memory_order. He also pointed out some issues with C++’s memory model and referenced a talk from Peter Sewell. Peter made the point that you need a more formal language than English to specify a memory model, and unfortunately C++’s memory model is defined in the standard which is English. So Ofek suggested that it is probably better to put effort into understanding the hardware memory model rather than C++’s and work from there.

Language Designers Panel

Link: Language Designers Panel - Bjarne Stroustrup, Guido van Rossum, Mads Torgersen & Emma Tracey

This was quite amazing to see in person. This was a panel with Bjarne (C++), Mads Torgersen (C#) and Guido (Python) all talking about what goes into designing a language, making it successful, and cultivating a community around it. Definitely worth a watch. Some key facts that I took away:

1. It really helps to be Danish to make a popular programming language. Denmark has produced a disproportionate amount of popular programming languages.
2. Bjarne and Mads were born in the same hospital. Some coincidence that!
3. Bjarne has some critiques of democracy -> Essentially he is a little annoyed that everyone’s vote is equal which means that more knowledgeable and experienced engineers can get overruled on important topics. I took this as Bjarne talking about his experiences with Contracts here. He gave Brexit as an example of a horrific decision that was made on slim margins by an uninformed populace.
4. Guido “rage quit” from being the BDFL of Python over the walrus (:=) operator -> this eventually led to “The steering council” for Python.
5. C# seems like a chill language to be a part of -> Mads points out that C++ and Python have a lot more fanatics, and that can make feedback and criticism more vitriolic. But in C# land, things seem easier. He can’t recall a time when a decision ever split the committee… like contracts in C++ have
6. Python conferences typically have a 50/50 gender split in speakers. Guido also pointed out that he felt that it was not great that there was only 1 woman involved in the fireside committee chat (Nina Rans).