CppCon 2026

The C++ community is growing fast. C++ is being used in critical applications. C++ can be used in ways that ensures correctness, simplicity, performance, and maintainability. How can we ensure that it is used is such desirable ways? How can we teach new and old C++ developers to do so?
The general strategy is called “subset of superset” and is based on the idea that by extending (“supersetting”) by adding libraries, we can simplify static analysis to where we can remove undesirable uses (“subsetting”) without damaging expressiveness or efficiency. Where run-time checks are necessary, such as to catch out-of-range accesses in hardened libraries, static analysis can be used to minimize the number of checks.
The strategy is supported by the “Profiles” framework, that allows us to require or suppress specific sets of guarantees, called profiles.
As examples, I show how to eliminate uninitialized-object errors and container-invalidation errors (a kind of dangling pointer errors) using the profiles framework and implementations of the “Initialization” and “invalidation” profiles. Both with zero run-time cost.

This Language Designers Panel features three of the people who decide what the languages you use every day actually become:

• Bjarne Stroustrup, the creator of C++ (who will have just given his own Monday conference kickoff keynote the day before)
• Guido van Rossum, the creator of Python
• Mads Torgersen, the lead designer of C# and Anders Hejlsberg’s successor in that role
• Moderator: Emma Tracey, founder of CultRepo and producer of its new feature film C++: The Documentary and Python: The Documentary

Three living and growing languages used by millions of developers, three design philosophies, one stage, one conversation.
Bjarne and Guido have never been on stage together anywhere and may never be again; add Mads to the stage, and we expect this special moment to be watched, cited, and argued over for years. You can be in the room when it happens.
Why should a C++ audience care about a panel that is two-thirds “other languages”? The answer is that these languages are two of C++’s closest neighbors and are used together all the time.

• Python is, by the numbers, C++’s truest sister language. In the Standard C++ Foundation’s annual C++ developer survey, when we ask which other languages C++ programmers use, Python always comes first, consistently around 70 percent — ahead even of C, which you might expect to win and is consistently around 45 percent. If you write C++, the odds are very good that you also write Python; the two have grown up side by side, gluing and being glued, and the relationship only deepens each year.
• C# and C++ are the two dominant languages on Windows, and the two are constantly used together — native performance underneath, managed productivity on top — so the person designing C# is designing part of the world that a great many C++ developers ship into.

So this is a conversation among the architects of the three languages most of us actually live in. What do they envy in one another’s designs? Where do they think they got it right, and where would they start over? How do you steer a language with millions of users and decades of existing code without breaking the people who depend on you? And the lessons to learn from their shared experience reach well beyond language design — the same instincts that shape a language will sharpen how you design your own libraries and products. Bring your own questions, too — you will not get a chance like this often.

C++ is adding major expressive power (e.g., reflection) and addressing weaknesses (e.g., memory safety hardening) at exactly the moment when chip supply and power budgets are raising the value of what people came to C++ for in the first place: control over memory layout (space) and deterministic performance (time). This talk is about that convergence, in two parts.
First, we cover the latest developments in ISO C++ itself, where the committee completed technical work on C++26 in March 2026, and then in June voted the first additions into the working draft for C++29:

• Key C++26 language improvements like reflection and the initial round of memory safety hardening, and standard library performance enhancers like std::simd and std::execution.
• A new Annex in the C++29 working draft cataloging every case of core language undefined behavior, the first step toward addressing it systematically rather than one paper at a time.
• Draft “profiles” for stronger portable memory safety guarantees, now being prototyped and targeted at C++29.

Second, we consider how quickly both hardware and software are moving in the industry around us. This year, capital is pouring into silicon and power at a jaw-dropping rate, and agentic systems are arriving with new capabilities and new failure modes. We’ll see how both affect C++ programming in the trenches:

• Why performance efficiency has been enduringly important, from the 1940s through to today and with no end in sight.
• How current industry data (SlashData, IDC) documents sustained growth in demand for professional programmers, especially who know languages that can operate under real space and time constraints.
• What AI does and doesn’t change about any of it: a pragmatic view both of where AI has shown real benefit in our programming world, and of what it’s not good at (yet, or ever).

Throughout, we might hear a little grumbling from the speaker about how he has always written his own talk titles and abstracts and prose using em-dashes, but now can’t use em-dashes anymore because of, well, you know.