Home »

CppCon 2025 How C++26 Changes the Way We Write Code -- Timur Doumler

By Blog Staff | Aug 6, 2025 09:10 AM | Tags: None

Registration is now open for CppCon 2025! The conference starts on September 13 and will be held in person in Aurora, CO. To whet your appetite for this year’s conference, we’re posting some upcoming talks that you will be able to attend this year. Here’s another CppCon future talk we hope you will enjoy – and register today for CppCon 2025!

How C++26 Changes the Way We Write Code

Monday, September 15 11:00 - 120:00 MDT

by Timur Doumler

Summary of the talk:

After the release of C++20, with groundbreaking new features like coroutines, concepts, ranges, and modules, and the more modest feature set of C++23, the upcoming C++26 Standard is shaping up to be another major milestone.

Trivial relocation evolves move semantics to the next level to unlock significant new performance benefits; contract assertions introduce portable, scalable, and configurable correctness checks for identifying program defects and making C++ code safer; and the new execution control library provides a powerful generic framework that redefines how to do asynchronous programming in C++. Finally, the most eagerly anticipated feature of C++26 — reflection — will profoundly reshape how we reason about C++ and what we can accomplish with it.

This talk is the latest installment in a popular series of talks about how each new C++ Standard changes the way we write code — from everyday idioms to advanced patterns — with a practical focus on what matters most to real-world developers. This is not a firehose talk that tries to cram as many additions to the latest Standard as possible into one hour. Instead, we focus deliberately on just a handful of particularly impactful features and highlight the essential parts that every C++ developer needs to know.


Timur Doumler is the co-host of CppCast and an active member of the ISO C++ standard committee, where he is currently co-chair of SG21, the Contracts study group. Timur started his journey into C++ in computational astrophysics, where he was working on cosmological simulations. He then moved into the audio and music technology industry, where he has been working for over a decade and co-founded the music tech startup Cradle. In the past, Timur also worked for JetBrains, first as a developer on CLion's C++ parser and later as a Developer Advocate for C++ developer tools. Currently, Timur lives in Finland, where he is organising the monthly C++ Helsinki meetup. Timur is passionate about clean code, good tools, low latency, and the evolution of the C++ language.

Variadic Class Template Arguments -- Sandor Dargo

By Blog Staff | Aug 5, 2025 08:49 AM | Tags: None

SANDOR_DARGO_ROUND.JPGVariadic templates are a powerful C++ feature that allow template classes or functions to accept an arbitrary number of parameters. In this article, we’ll explore how to combine them with class templates and examine the various ways the parameter pack can be expanded.

Variadic Class Template Arguments

by Sandor Dargo

From the article:

Let’s talk about class templates and variadic parameters. How to use them in combination?

But first of all, what are variadic templates?

Variadic template don’t accept a fixed size of parameters, but anything from one to more. The set of parameters is called the parameter pack.

In the template parameter list, we can see the three dots (...) signaling the pack after the typename or class keywords, or after the constraints. Then later in the function / constructor parameter list, you can observe it right after the actual type name, and finally once the pack is expanded, it comes after the packed variable name.

Variadic arguments can be used in so many different ways both with function and class templates. Today, we are focusing on class templates.

When you are using variadic templates with class templates, the expansion can happen at different places. You might expand the parameter pack

  • within the constructor or any other member function
  • when declaring a member variable
  • at the inheritance list
  • in a using declaration
  • in friend declarations

 

CppCon 2025 Cutting C++ Exception Time by 93.4% -- Khalil Estell

By Blog Staff | Aug 4, 2025 11:07 AM | Tags: None

Registration is now open for CppCon 2025! The conference starts on September 13 and will be held in person in Aurora, CO. To whet your appetite for this year’s conference, we’re posting some upcoming talks that you will be able to attend this year. Here’s another CppCon future talk we hope you will enjoy – and register today for CppCon 2025!

Cutting C++ Exception Time by 93.4%

Monday, September 15 11:00 - 12:00 MDT

by Khalil Estell

Summary of the talk:

Have you ever been "nerd sniped"? When I realized that exceptions are capable of reducing binaries sizes, it felt like the only thing standing in the way of its adoption was its performance concerns. I couldn't let it go. I wanted to see how far the algorithm could be pushed. In 2024, I set out to just that: making C++ exceptions blazingly fast for embedded platforms. A year later, I've achieved a +90% performance improvement for ARM microcontrollers.

This talk takes you behind the scenes of this journey. I'll share the complete roadmap—from initial benchmarking to optimization—revealing techniques applicable to any performance-critical C++ system. But this isn't just a technical story; it's a testament to the power of community collaboration and how the C++ community summoned this talk. Even if you've sworn off exceptions forever, this talk still delivers value. It's a course in performance optimization which applies across the entire C++ ecosystem.

Join me for a deep dive into what happens when obsession meets optimization—and discover just how fast C++ can really be. Whether you're writing embedded firmware, high-frequency trading systems, a game, or a web server in C++ you'll walk away with techniques to dramatically improve your code.

You'll discover:

  1. Building precise measurement frameworks for cpu cycle improvements
  2. Navigating and modernizing a 25-year-old codebase
  3. Demystifying and eliminating the actual sources of non-determinism
  4. Leveraging community expertise to shape product requirements
  5. Using data-oriented design to convert O(log(n)) operations to O(1)
  6. Working within fixed ABI constraints without compromising performance
  7. Exploring the future landscape of C++ exception handling


Khalil is a ISO C++ Committee Member and has extensive experience writing production firmware.

CppCon 2025 Concept-based Generic Programming -- Bjarne Stroustrup

By Blog Staff | Aug 3, 2025 01:56 AM | Tags: None

Registration is now open for CppCon 2025! The conference starts on September 13 and will be held in person in Aurora, CO. To whet your appetite for this year’s conference, we’re posting some upcoming talks that you will be able to attend this year. Here’s another CppCon future talk we hope you will enjoy – and register today for CppCon 2025!

Concept-based Generic Programming

Monday, September 15 08:45 - 10:30 MDT

by Bjarne Stroustrup

Summary of the talk:

This talk presents programming techniques to illustrate the facilities and principles of C++ generic programming using concepts. Concepts are C++’s way to express constraints on generic code. As an initial example, it provides a simple type system that eliminate narrowing conversions and provides range checking.

Concepts are used throughout to provide user-defined extensions to the type system. The aim is to show their utility and the fundamental ideas behind them, rather than to provide a detailed or complete explanation of C++’s language support for generic programming or the extensive support provided by the standard library.

The final sections briefly present design rationales and origins for key parts of the concept design, including use patterns, the relationship to Object-Oriented Programming, value arguments, syntax, concept type-matching, and definition checking. They also mention static reflection, a C++26 improvements in the support of general programming.


Bjarne Stroustrup is the designer and original implementer of C++ as well as the author of The C++ Programming Language (4th Edition) and A Tour of C++ (3rd edition), Programming: Principles and Practice using C++ (2nd Edition), and many popular and academic publications. He is a professor of Computer Science in Columbia University in New York City. Dr. Stroustrup is a member of the US National Academy of Engineering, and an IEEE, ACM, and CHM fellow. He received the 2018 Charles Stark Draper Prize, the IEEE Computer Society's 2018 Computer Pioneer Award, and the 2017 IET Faraday Medal. He did much of his most important work in Bell Labs. His research interests include distributed systems, design, programming techniques, software development tools, and programming languages. To make C++ a stable and up-to-date base for real-world software development, he has been a leading figure with the ISO C++ standards effort for more than 30 years. He holds a master’s in Mathematics from Aarhus University, where he is an honorary professor in the Computer Science Department, and a PhD in Computer Science from Cambridge University, where he is an honorary fellow of Churchill College. www.stroustrup.com

C++26: Disallow Binding a Returned Reference to a Temporary -- Sandor Dargo

By Blog Staff | Jul 25, 2025 02:57 PM | Tags: None

SANDOR_DARGO_ROUND.JPGThis change in C++26 tightens the rules around returning references to temporaries — and that’s a good thing. It turns dangerous, bug-prone code into immediate compilation errors, making code safer and easier to reason about. It also reflects a broader trend in modern C++: giving programmers stronger guarantees and better diagnostics, even at the cost of breaking some old patterns.

C++26: Disallow Binding a Returned Reference to a Temporary

by Sandor Dargo

From the article:

In short, thanks to P2748R5 by Brian Bi, it’s no longer possible to return a reference that binds to a temporary expression, and that’s just lovely.

What exactly is changing?

Often, a proposal modifies a lot of wording, and it’s not practical to start by reading through it all. But in this case, the changes are small and easy to digest, so let’s dive in.

This line is being removed:

“The lifetime of a temporary bound to the returned value in a function return statement (8.7.4) is not extended; the temporary is destroyed at the end of the full-expression in the return statement.”

And this line is being added (excluding the examples we’ll discuss in a moment):

“In a function whose return type is a reference, other than an invented function for std::is_convertible ([meta.rel]), a return statement that binds the returned reference to a temporary expression ([class.temporary]) is ill-formed.”

There are two interesting shifts here:

  • The language becomes more specific. It doesn’t merely mention “temporaries” but refers directly to references binding to temporary expressions, with certain exceptions.
  • The effect isn’t just that lifetime extension doesn’t happen, it’s now a compilation error. The code is ill-formed.

constexpr Functions: Optimization vs Guarantee -- Andreas Fertig

By Blog Staff | Jul 23, 2025 02:53 PM | Tags: None

me.pngConstexpr has been around for a while now, but many don’t fully understand its subtleties. Andreas Fertig explores its use and when a constexpr expression might not be evaluated at compile time.

constexpr Functions: Optimization vs Guarantee

by Andreas Fertig

From the article:

The feature of constant evaluation is nothing new in 2023. You have constexpr available since C++11. Yet, in many of my classes, I see that people still struggle with constexpr functions. Let me shed some light on them.

What you get is not what you see

One thing, which is a feature, is that constexpr functions can be evaluated at compile-time, but they can run at run-time as well. That evaluation at compile-time requires all values known at compile-time is reasonable. But I often see that the assumption is once all values for a constexpr function are known at compile-time, the function will be evaluated at compile-time.

I can say that I find this assumption reasonable, and discovering the truth isn’t easy. Let’s consider an example (Listing 1).

constexpr auto Fun(int v)
{
  return 42 / v; ①
}

int main()
{
  const auto f = Fun(6); ②
  return f;              ③
}
The constexpr function Fun divides 42 by a value provided by the parameter v ①. In ②, I call Fun with the value 6 and assign the result to the variable f.

Three types of name lookups in C++ -- Sandor Dargo

By Blog Staff | Jul 21, 2025 02:50 PM | Tags: None

SANDOR_DARGO_ROUND.JPGLet's revisit a core concept in C++: how the compiler finds the names you use in your code. From qualified and unqualified name lookups to the special case of Argument-Dependent Lookup (ADL), understanding these mechanisms is essential for writing clear and correct C++ programs.

Three types of name lookups in C++

by Sandor Dargo

From the article:

Let’s get back to some basics this week and talk about name lookups in C++. In other words: when you refer to a symbol in your code, how does the compiler find it?

Essentially, we can differentiate between three kinds of lookups:

  • Qualified name lookup
  • Unqualified name lookup
  • Argument-Dependent Lookup (ADL)

Let’s explore them in that order.

Qualified Name Lookup

The term qualified refers to symbols that are explicitly scoped using the :: operator. In other words, these are names that appear to the right of a ::, such as x in a::b::x.

Before the compiler can perform a qualified name lookup, it must first resolve the left-hand side of the :: operator. This identifies the namespace or class being referenced.

Qualified name lookup is relatively simple: it only searches the explicitly named scope. It does not search enclosing or outer scopes.

Why does C++ think my class is copy-constructible when it can’t be copy-constructed? -- Raymond Chen

By Blog Staff | Jul 17, 2025 02:47 PM | Tags: None

RaymondChen_5in-150x150.jpgIn C++, the presence of a user-declared (but not explicitly deleted) copy constructor is enough for the type to be considered copy-constructible by traits like std::is_copy_constructible. However, whether that constructor is instantiable is a separate matter—if it attempts to call a deleted base copy constructor, you'll still get a compile-time error when you actually try to use it.

Why does C++ think my class is copy-constructible when it can’t be copy-constructed?

by Raymond Chen

From the article:

Consider the following scenario:

template<typename T>
struct Base
{
    // Default-constructible
    Base() = default;

    // Not copy-constructible
    Base(Base const &) = delete;
};

template<typename T>
struct Derived : Base<T>
{
    Derived() = default;
    Derived(Derived const& d) : Base<T>(d) {}
};

// This assertion passes?
static_assert(
    std::is_copy_constructible_v<Derived<int>>);

Why does this assertion pass? It is plainly evident that you cannot copy a Derived<int> because doing so will try to copy the Base<int>, which is not copyable.