: Standard C++

Home » Blog » Categories »

« Prev Next »

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

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?

C++20 Concepts for Nicer Compiler Errors -- Daniel Lemire

By Blog Staff | Jun 19, 2025 05:13 PM | Tags: None

Templates are one of C++’s most powerful features, enabling developers to write generic, reusable code—but they come with a cost: notoriously verbose and opaque error messages. With the introduction of concepts in C++20, we can now impose clear constraints on template parameters and get far more helpful diagnostics when something goes wrong.

C++20 Concepts for Nicer Compiler Errors

by Daniel Lemire

From the article:

In C++, templates enable generic programming by allowing functions and classes to operate on different data types without sacrificing type safety. Defined using the template keyword, they let developers write reusable, type-agnostic code, such as functions (e.g., template <typename T> max(T a, T b)) or classes (e.g., std::vector), where the type T is specified at compile time.

Historically, the C++ language has tended to produce complicated compiler error messages. The main culprit is template metaprogramming. C++ templates are powerful but complex. When errors occur in template code, the compiler generates long, verbose messages with nested type information, often involving deep template instantiations. A simple mistake in a template function can produce a message spanning multiple lines with obscure type names.

Let us consider an example. In C++, we often use the ‘Standard Template Library (STL)’. It includes a useful dynamic array template: std::vector. A vector manages a sequence of elements with automatic memory handling and flexible sizing. Unlike fixed-size arrays, it can grow or shrink at runtime through operations like push_back to append elements or pop_back to remove them. You can store just about anything in an std::vector but there are some limits. For example, your type must be copyable.

Announcing the 3rd Keynote for Meeting C++ 2025: its Anthony Williams!

By Meeting C++ | Jun 19, 2025 08:46 AM | Tags: meetingcpp events conference

With this announcement the keynotes for this years Meeting C++ conference are complete!

Announcing the 3rd Keynote for Meeting C++ 2025: its Anthony Williams!

by Jens Weller

From the article:

Today I have the honor to announce that Anthony Williams completes the keynotes for Meeting C++ 2025!

Anthony Williams is well known for his book "C++ Concurrency in Action", has been an active in the committee through the BSI since 2001. He is well known for his work on concurrency and one of the architects and implementers of std::thread and other concurrency features in C++. He gave an An introduction to multithreading in C++20 at Meeting C++ 2022 in the online track. I am looking forward to welcome Anthony in person in Berlin this year!

CppCon 2024 Guide to Linear Algebra With the Eigen C++ Library -- Daniel Hanson

By Blog Staff | Jun 18, 2025 01:19 PM | Tags: None

Guide to Linear Algebra With the Eigen C++ Library

by Daniel Hanson

Summary of the talk:

Linear algebra is an essential part of scientific programming, particularly in domains such as quantitative finance, data science, physics, and medical research. It is also relevant to imaging in game development. As C++ did not have all the convenient built-in multidimensional array capabilities and supporting libraries that came with typical Fortran platforms, scientific programmers making the transition to C++ back in the late 1990’s and early 2000's often found themselves in an inconvenient situation with limited options. These included building up this functionality mostly from scratch, wrestling with interfaces to numerical Fortran libraries such as BLAS and LAPACK, or somehow convincing management to invest in a third-party commercial C++ linear algebra library.

The situation has improved substantially over the years with the development of several well-regarded open-source linear algebra libraries for C++. One in particular that has become popular, first released in 2006, is the Eigen library. It has been adopted for use within both the TensorFlow machine learning library and the Stan Math Library, as well as at CERN, and it can also be found in the implementation of high-performance quantitative trading strategies in C++.

In this talk, we will examine the setup and basics of the Eigen library, followed by a discussion of some of its more advanced features, including applications of matrix decompositions frequently used in quantitative work, as well as its compatibility with STL algorithms. It will conclude with an overview of how it can be used within the context of the C++26 BLAS interface proposal (P1673), via an interface with std::mdspan now available in C++23.

Using C++ type aliasing to avoid the ODR problem with conditional compilation part 1 -- Raymond Chen

By Blog Staff | Jun 17, 2025 05:10 PM | Tags: None

C++’s One Definition Rule (ODR) can cause subtle and hard-to-detect issues when compile-time switches lead to inconsistent definitions across translation units. However, by using type aliases and template instantiation, we can sidestep these violations—giving each module its own definition without triggering undefined behavior.

Using C++ Type Aliasing to Avoid the ODR Problem with Conditional Compilation, Part 1

by Raymond Chen

From the article:

Some time ago, I discussed the C++ concept of ill-formed no diagnostic required (IFNDR). A common accidental source of this is violating the One Definition Rule (ODR) by defining a class or function differently based on compile-time switches.
// widget.h

struct Widget
{
    Widget();

    void SetName(std::string const& name);

    ⟦ more stuff ⟧

#ifdef EXTRA_WIDGET_DEBUGGING
    Logger m_logger;

    void Log(std::string const& message) {
        m_logger.log(message);
    }
#else
    void Log(std::string const& message) {
        // no extra logging
    }
#endif

    std::string m_name;
};
If one .cpp file is compiled with extra widget debugging enabled, but another is compiled with extra widget debugging disabled, and they are linked together, then you have a One Definition Rule violation because the Widget structure and the Widget::Log method have conflicting definitions.

But all is not lost.

CppCon 2024 Amortized O(1) Complexity in C++ -- Andreas Weis

By Blog Staff | Jun 16, 2025 01:14 PM | Tags: None

Lightning Talk: Amortized O(1) Complexity in C++

by Andreas Weis

Summary of the talk:

We will take a quick look at how amortized analysis for algorithms works. We will use two examples from the standard library to demonstrate this and show how in one place, the standard's interpretation of amortized constant complexity is at odds with the usual use of the term.