Home »

Using RAII to remedy defect where not all code paths performed required exit actions -- Raymond Chen

By Blog Staff | Nov 28, 2025 03:22 PM | Tags: None

RaymondChen_5in-150x150.jpgA missing DismissUI() call on one code path led to a subtle bug—but rather than patching it with more try/catch and return logic, there’s a cleaner C++ solution. This article shows how to use RAII and wil::scope_exit to guarantee cleanup across all code paths, even in asynchronous callbacks.

Using RAII to remedy a defect where not all code paths performed required exit actions

by Raymond Chen

From the article:

A team asked me to review their pull request that fixed a bug that was caused by failing to perform some required action along all code paths. Here’s a simplified sketch:

void MySpecialFeature::OnButtonClick()
{
    try {
        auto file = PickFile();
        if (!file) {
            DismissUI();
            return;
        }

        if (ConfirmAction()) {
            if (m_useAlgorithm1) {
                // StartAlgorithm1 invokes the lambda when finished.
                StartAlgorithm1(file, [self = shared_from_this()] {
                    self->DismissUI();
                });
            } else {
                RunAlgorithm2(file);
                DismissUI();
            }
        } else { // this block was missing
           DismissUI(); 
        } 
    } catch (...) {
        DismissUI();
    }
}

Open wide: Inspecting LLVM 21 with static analysis

By Andrey Karpov | Nov 28, 2025 05:54 AM | Tags: static analysis sast pvs-studio llvm 21 llvm

It has been over a year since the last check of the LLVM project with PVS-Studio, and in that time, two releases have come out. So, it's a good time to get back and analyze the fresh LLVM 21.

Open wide: Inspecting LLVM 21 with static analysis

by Nikita Terentev

From the article:

As we can see, error logging will never be executed, and, moreover, execution will always continue with potentially incorrect behavior. Here's what git blame reports: the code celebrates its tenth anniversary in November. One might think its meaning had changed over time. But no, history confirms that Defs has always been DenseMap, and its count function only returned 0 or 1 back then. If we search for other similar checks, we see that the count result is used as a binary value everywhere.

 

How to Iterate through std::tuple: C++26 Packs and Expansion Statements -- Bartlomiej Filipek

By Blog Staff | Nov 25, 2025 02:54 PM | Tags: None

filipek-howtoiterate.pngIn this final part of the tuple-iteration mini-series, we move beyond C++20 and C++23 techniques to explore how C++26 finally brings first-class language support for compile-time iteration. With structured binding packs (P1061) and expansion statements (P1306), what once required clever template tricks can now be written in clean, expressive, modern C++.

C++ Templates: How to Iterate through std::tuple: C++26 Packs and Expansion Statements

by Bartlomiej Filipek

From the article:

In part 1 of this mini-series, we looked at the basics of iterating over a std::tuple using index_sequence and fold expressions. In part 2, we simplified things with std::apply and even created helpers like for_each_tuple and transform_tuple.

So far, we used C++ features up to C++20/23… but now, in C++26, we finally get language-level tools that make tuple iteration straightforward and expressive. In this article, we’ll explore two new techniques:

  • Structured bindings can introduce a pack - P1061 - turn a tuple into a pack of variables.
  • Expansion statements P1306 - the ultimate “compile-time loop” syntax.

 

Concept-Based Generic Programming -- Bjarne Stroustrup

By Bjarne Stroustrup | Nov 22, 2025 02:14 PM | Tags: None

A new paper:

Bjarne Stroustrup: Concept-Based Generic Programming

https://www.stroustrup.com/Concept-based-GP.pdf

We present 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, we provide a simple type system that eliminates narrowing conversions and provides range checking without unnecessary notational or run-time overhead.

User-Defined Formatting in std::format -- Spencer Collyer

By Blog Staff | Nov 21, 2025 02:51 PM | Tags: None

logo.pngstd::format allows us to format values quickly and safely. Spencer Collyer demonstrates how to provide formatting for a simple user-defined class.

User-Defined Formatting in std::format

by Spencer Collyer

From the article:

In a previous article [Collyer21], I gave an introduction to the std::format library, which brings modern text formatting capabilities to C++.

That article concentrated on the output functions in the library and how they could be used to write the fundamental types and the various string types that the standard provides.

Being a modern C++ library, std::format also makes it relatively easy to output user-defined types, and this series of articles will show you how to write the code that does this.

There are three articles in this series. This article describes the basics of setting up the formatting for a simple user-defined class. The second article will describe how this can be extended to classes that hold objects whose type is specified by the user of your class, such as containers. The third article will show you how to create format wrappers, special purpose classes that allow you to apply specific formatting to objects of existing classes.

A note on the code listings: The code listings in this article have lines labelled with comments like // 1. Where these lines are referred to in the text of this article, it will be as ‘line 1’ for instance, rather than ‘the line labelled // 1’.

std::ranges may not deliver the performance that you expect -- Daniel Lemire

By Blog Staff | Nov 19, 2025 02:48 PM | Tags: None

Capture-decran-le-2025-10-05-a-17.34.45-825x510.pngModern C++ offers elegant abstractions like std::ranges that promise cleaner, more expressive code without sacrificing speed. Yet, as with many abstractions, real-world performance can tell a more nuanced story—one that every engineer should verify through careful benchmarking.

std::ranges may not deliver the performance that you expect

by Daniel Lemire

From the article:

Good engineers seek software code that is ‘simple’ in the sense that we can read and understand it quickly. But they they also look for highly performant code.

For the last 20 years, we have been offering programmers the possibility to replace conventional for loops with a more functional approach. To illustrate, suppose that you want to extract all even integers from a container and create a new container. In conventional C++, you would proceed with a loop, as follows.

std::vector<int> even_numbers;
for (int n : numbers) {
 if (n % 2 == 0) {
 even_numbers.push_back(n);
 }
}

C++26: std::optional -- Sandor Dargo

By Blog Staff | Nov 17, 2025 02:43 PM | Tags: None

SANDOR_DARGO_ROUND.JPGIf you’re a regular reader of Sandor's blog, you know he's been sharing what he learned about new C++ language and library features ever since C++20. You probably also read his CppCon 2025 Trip Report. And this post is where the two come together.

C++26: std::optional<T&>

by Sandor Dargo

From the article:

At CppCon I attended a great talk by Steve Downey about std::optional<T&>. Steve is the father of optional references—he co-authored P2988R12 with Peter Sommerlad.

Let’s start with a little history. By now — at the end of 2025 — even C++17 feels like history. That’s when std::optional<T> was introduced, giving us a way to represent “maybe a value” with value semantics, instead of relying on pointers. But std::optional in C++17 (and later) couldn’t hold references — unless you wrapped them in std::reference_wrapper.

C++26 finally fixes this gap.

What is std::optional<T&>?

std::optional<T&> has three key characteristics:

  • Unlike std::optional<T>, it is not an owning type. It simply refers to an existing object.
  • It provides both reference and value-like semantics.
  • Internally, it behaves like a pointer to T, which may also be nullptr.

This last point is interesting: while optional<T> can be seen as variant<T, monostate>, optional<T&> is closer to variant<T&, nullptr_t>. In practice, it’s a safer alternative to a non-owning raw pointer.

The problem with inferring from a function call operator is that -- Raymond Chen

By Blog Staff | Nov 14, 2025 02:39 PM | Tags: None

RaymondChen_5in-150x150.jpgIn this post, we’ll take a closer look at how to extend the earlier callback wrapper mechanism to handle regular function pointers as well as member functions. Along the way, we’ll examine some of the subtleties of inferring function pointer types from callable objects—especially when lambdas with auto parameters enter the picture.

The problem with inferring from a function call operator is that there may be more than one

by Raymond Chen

From the article:

Some time ago, I wrote briefly on writing a helper class for generating a particular category of C callback wrappers around C++ methods. This particular mechanism used a proxy object with a templated conversion operator to figure out what function pointer type it was being asked to produce.¹

But what about taking a std::invoke‘able object and inferring the function pointer from the parameters that the invoke‘able’s operator() accepts?

Sure, you could try to do that, but there’s a catch: There might be more than one operator().

The common case of this is a lambda with auto parameters.

RegisterCallback(
    CallableWrapper([](auto first, auto second, auto third) {
        ⟦ ... ⟧
    }, context);