C++26: Erroneous Behaviour -- Sandor Dargo

By Blog Staff | Jul 3, 2025 02:29 PM | Tags: None

C++’s undefined behaviour impacts safety. Sandor Dargo explains how and why uninitialised reads will become erroneous behaviour in C++26, rather than being undefined behaviour.

C++26: Erroneous Behaviour

by Sandor Dargo

From the article:

If you pick a random talk at a C++ conference these days, there is a fair chance that the speaker will mention safety at least a couple of times. It’s probably fine like that. The committee and the community must think about improving both the safety situation and the reputation of C++.

If you follow what’s going on in this space, you are probably aware that people have different perspectives on safety. I think almost everybody finds it important, but they would solve the problem in their own way.

A big source of issues is certain manifestations of undefined behaviour. It affects both the safety and the stability of software. I remember that a few years ago when I was working on some services which had to support a 10× growth, one of the important points was to eliminate undefined behaviour as much as possible. One main point for us was to remove uninitialized variables which often lead to crashing services.

Thanks to P2795R5 by Thomas Köppe, uninitialized reads won’t be undefined behaviour anymore – starting from C++26. Instead, they will get a new behaviour called ‘erroneous behaviour’.

The great advantage of erroneous behaviour is that it will work just by recompiling existing code. It will diagnose where you forgot to initialize variables. You don’t have to systematically go through your code and let’s say declare everything as auto to make sure that every variable has an initialized value. Which you probably wouldn’t do anyway.

Writing Senders -- Lucian Radu Teodorescu

By Blog Staff | Jul 1, 2025 02:26 PM | Tags: None

Senders/receivers can be used to introduce concurrency. Lucian Radu Teodorescu describes how to implement senders.

Writing Senders

by Lucian Radu Teodorescu

From the article:

If people are just using frameworks based on std::execution, they mainly need to care about senders and schedulers. These are user-facing concepts. However, if people want to implement sender-ready abstractions, they also need to consider receivers and operation states – these are implementer-side concepts. As this article mainly focuses on the implementation of sender abstractions, we need to discuss these two concepts in more detail.

A receiver is defined in P2300 as “a callback that supports more than one channel” [P2300R10]. The proposal defines a concept for a receiver, unsurprisingly called receiver. To model this concept, a type needs to meet the following conditions:

• It must be movable and copyable.
• It must have an inner type alias named receiver_concept that is equal to receiver_t (or a derived type).
• std::execution::get_env() must be callable on an object of this type (to retrieve the environment of the receiver).

A receiver is the object that receives the sender’s completion signal, i.e., one of set_value(), set_error(), or set_stopped(). As explained in the December 2024 issue [Teodorescu24], a sender may have different value completion types and different error completion types. For example, the same sender might sometimes complete with set_value(int, int), sometimes with set_value(double), sometimes with set_error(std::exception_ptr), sometimes with set_error(std::error_code), and sometimes with set_stopped(). This implies that a receiver must also be able to accept multiple types of completion signals.

C++26: constexpr Exceptions -- Sandor Dargo

By Blog Staff | Jun 27, 2025 02:07 PM | Tags: None

In recent weeks, we’ve explored language features and library features becoming constexpr in C++26. Those articles weren’t exhaustive — I deliberately left out one major topic: exceptions.

Starting with C++26, it will become possible to throw exceptions during constant evaluation. This capability is enabled through both language and library changes. Given the significance of this feature, it deserves its own dedicated post.

C++26: constexpr Exceptions

by Sandor Dargo

From the article:

P3068R6: Allowing exception throwing in constant-evaluation

The proposal for static reflection suggested allowing exceptions in constant-evaluated code, and P3068R6 brings that feature to life.

constexpr exceptions are conceptually similar to constexpr allocations. Just as a constexpr string can’t escape constant evaluation and reach runtime, constexpr exceptions also have to remain within compile-time code.

Previously, using throw in a constexpr context caused a compilation error. With C++26, such code can now compile — unless an exception is actually thrown and left uncaught, in which case a compile-time error is still issued. But the error now provides more meaningful diagnostics.

 

CppCon 2024 The UB Detector: constexpr -- Andreas Fertig

By Blog Staff | Jun 26, 2025 01:28 PM | Tags: None

Registration is now open for CppCon 2025! The conference starts on September 15 and will be held in person in Aurora, CO. To whet your appetite for this year’s conference, we’re posting videos of some of the top-rated talks from last year's conference. Here’s another CppCon talk video we hope you will enjoy – and why not register today for CppCon 2025!

Lightning Talk: The UB Detector: constexpr

by Andreas Fertig

Summary of the talk:

A constexpr function evaluated at compile time is free of any undefined behaviour they say. Do you think that statement is true as well?

Talks and a first schedule for Meeting C++ 2025

By Meeting C++ | Jun 26, 2025 06:51 AM | Tags: meetingcpp event conference community

This week Meeting C++ published the accepted talks and a first schedule for the conference in November.

Schedule for Meeting C++ 2025

The talks for Meeting C++ 2025

by Jens Weller

From the article:

Top 10 voted talks

    To Err is Human: Robust Error Handling in C++26 - Sebastian Theophil
    Seeing all possible paths forward - Hana Dusíková
    Code Reviews: Building Better Code and Stronger Teams - Sandor Dargo
    The Two memory Models - Anders Schau Knatten
    How to become obsolete: a guide to software engineering mentorship - Roth Michaels
    Branch Prediction: Lessons from the hot path - John Farrier
    Towards Safety and Security in C++26 - Daniela Engert
    The data-parallel types (SIMD) library in C++26 - Rainer Grimm
    The Code is Documentation Enough - Tina Ulbrich
    Range adaptors - 5 years after C++20 - Hannes Hauswedell
    Speed for free - current state of auto-vectorizing compilers - Stefan Fuhrmann

 

An option(al) to surprise you -- Andreas Fertig

By Blog Staff | Jun 25, 2025 02:01 PM | Tags: None

In today's post I share a learning of a customer with you. A while back, a customer asked me to join a debugging session. They had an issue they didn't (fully) understand.

An option(al) to surprise you

by Andreas Fertig

From the article:

The base

What I will show you is a much down-stripped and, of course, altered version. It was about a message system, but that's not important. Have a look at the code below.

You can see a class enum for a state and a function Worker. The function takes a State and a const char* message named data. The function's job is to create a std::optional containing the user data, a C-style string.

CppCon 2024 Modern C++ Error Handling -- Phil Nash

By Blog Staff | Jun 24, 2025 01:25 PM | Tags: None

Registration is now open for CppCon 2025! The conference starts on September 15 and will be held in person in Aurora, CO. To whet your appetite for this year’s conference, we’re posting videos of some of the top-rated talks from last year's conference. Here’s another CppCon talk video we hope you will enjoy – and why not register today for CppCon 2025!

Modern C++ Error Handling

by Phil Nash

Summary of the talk:

We’ve had exceptions in C++ since before the first standard. C++17 introduced std::optional and C++23 std::expected (along with the so-called Monadic Operations for both types).

What should we use and when?

Meanwhile we still have older approaches, such as boolean or error code returns, as well as global or thread local error status or pointer or reference arguments.

Do these still have a place?

And where does assert fit in? And the (hopefully) upcoming contracts?

Perhaps more importantly, once we’ve examined all the trade-offs, can we defer any of those decisions to when we are best positioned to commit to them?

Erroneous conditions can have a big impact on your code’s safety and security, so error handling shouldn’t just be left to the “exercise left for the reader” in the books we used to read. Let’s get this all straight.

Implementing a Struct of Arrays -- Barry Revzin

By Blog Staff | Jun 23, 2025 01:58 PM | Tags: None

Data-oriented design is all about reorganizing data for better performance, and Andrew Kelley’s talk on the topic—especially his use of Zig’s MultiArrayList—offered a compelling real-world example. Inspired by that, this post explores how we can achieve a similar “struct-of-arrays” approach in C++26 using reflection to build a SoaVector<T> that separates member storage for improved memory locality and performance.

Implementing a Struct of Arrays

by Barry Revzin

From the article:

Recently, I watched Andrew Kelley’s talk on Practical Data Oriented Design. It goes into some of the architectural changes he’s been making to the Zig compiler, with pretty significant performance benefit. Would definitely recommend checking out the talk, even if you’re like me and have never written any Zig.

About halfway through the talk, he shows a way to improve his memory usage by avoiding wasting memory. By turning this structure:

const Monster = struct { 
    anim : *Animation, 
    kind : Kind, 

    const Kind = enum { 
    snake, bat, wolf, dingo, human 
    }; 
}; 

var monsters : ArrayList(Monster) = .{}; 

into this one:

var monsters : MultiArrayList(Monster) = .{}; 

ArrayList(Monster) is what we could call std::vector<Monster>, and MultiArrayList(Monster) now stores the anims and kinds in two separate arrays, instead of one. That is, a struct of arrays instead of an array of structs. But it’s a tiny code change.

Reflection voted into C++26: "Whole new language" -- Herb Sutter

By Blog Staff | Jun 21, 2025 10:15 PM | Tags: None

The first trip report from the Sofia meeting is available:

Trip report: June 2025 ISO C++ standards meeting (Sofia, Bulgaria)

by Herb Sutter

From the article:

A unique milestone: “Whole new language”

Today marks a turning point in C++: A few minutes ago, the C++ committee voted the first seven (7) papers for compile-time reflection into draft C++26 to several sustained rounds of applause in the room. I think Hana “Ms. Constexpr” Dusíková summarized the impact of this feature best a few days ago, in her calm deadpan way… when she was told that the reflection paper was going to make it to the Saturday adoption poll, she gave a little shrug and just quietly said: “Whole new language.”

Mic drop.

CppCon 2024 How Far Should You Indent Your Code? - The Number Of The Counting -- Dave Steffen

By Blog Staff | Jun 20, 2025 01:22 PM | Tags: None

Registration is now open for CppCon 2025! The conference starts on September 15 and will be held in person in Aurora, CO. To whet your appetite for this year’s conference, we’re posting videos of some of the top-rated talks from last year's conference. Here’s another CppCon talk video we hope you will enjoy – and why not register today for CppCon 2025!

Lightning Talk: How Far Should You Indent Your Code? - The Number Of The Counting

by Dave Steffen

Summary of the talk:

Coding Standards have to say something about how we indent our code.  Is there a definitive answer?