Blog

Subobject Polymorphic Overlay Pattern -- Félix-Olivier Dumas

In this article, I explore the Subobject Polymorphic Overlay Pattern (SPO), an experimental architectural idiom that inverts the classic contract model of static polymorphism. Instead of the implementation inheriting from an interface, the interface becomes a clean, selective view over an independent implementation. The result is zero-overhead compile-time polymorphism that avoids some of the usual drawbacks of traditional CRTP and std::variant based approaches, while still remaining explicit about its trade-offs and experimental nature.

Subobject Polymorphic Overlay Pattern (SPO): An Architectural Idiom for Static Polymorphism

by Félix-Olivier Dumas

From the article:

Nowadays, C++ is one of the most influential programming languages in the world. Over the past 40 years, it has proven itself in fields ranging from aerospace engineering to your basement at 2 a.m. [...]

To this day, there are two major categories when it comes to polymorphism in C++: static polymorphism and dynamic polymorphism. Although they share the same underlying philosophy, the reality is that they are extremely different from one another, both in implementation and in usage.

 

 

Compile-Time Policy Composition for Password Validation -- Daniel Gómez Vergel

This article presents the design of a simple password validator that can be configured at compile time by composing independent validation policies.

Compile-Time Policy Composition for Password Validation

by Daniel Gómez Vergel

From the article:

A traditional object-oriented solution could rely on dynamic polymorphism and the Decorator pattern to select and combine validation policies at runtime. In this article, we take a different approach: policy composition is performed entirely at compile time, making the validator configuration part of the type itself.

The example serves as a vehicle for exploring useful C++ techniques, including policy-based design, concepts, and other modern language features such as template for expansions.

Your buffer is not a struct yet -- Mateusz Pusz

The third installment in Mateusz Pusz's series on C++ rules experienced developers quietly get wrong, this one works through when casting a byte buffer to a struct is undefined behavior and when it is not, using C++20 implicit-lifetime types and implicit object creation, and the C++23 std::start_lifetime_as for the remaining case.

Your buffer is not a struct yet

by Mateusz Pusz

Published so far:

From the article:

Whether casting a buffer to a struct is undefined behavior depends on two things: whether the type is implicit-lifetime, and whether an operation that implicitly creates objects ran on that storage. A std::byte array, operator new, std::malloc, std::memcpy, or std::bit_cast brings the object into being. Defining an int[] does not, and a reinterpret_cast never does. When the object is already there, the cast just types the pointer. When it is not, begin the lifetime yourself: std::start_lifetime_as for implicit-lifetime types, since it leaves the bytes untouched, and placement new or std::construct_at when you actually want to construct a fresh value.

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

SANDOR_DARGO_ROUND.JPGC++26’s std::polymorphic brings value semantics to polymorphic objects, eliminating much of the boilerplate traditionally required with std::unique_ptr. It enables deep copying while preserving dynamic types—without virtual clone() methods or hand-written copy operations.

C++26: std::polymorphic

by Sandor Dargo

From the article:

In the previous article, we looked at std::indirect — C++26’s answer to the “I need a heap-allocated member with value semantics” problem. indirect<T> always stores exactly a T. But what if you need to store a Circle or a Rectangle through a Shape base class — and copy it without slicing?

That’s std::polymorphic<T>, the other half of P3019R14. It owns a heap-allocated object whose dynamic type may be T or any type derived from T. Copying performs a type-erased deep copy that preserves the dynamic type. No virtual clone() needed.

The clone() tax

To have a copyable collection of polymorphic objects, every derived class needs a virtual clone() method. Let’s see what that looks like:

class Shape {
public:
    virtual ~Shape() = default;
    virtual std::unique_ptr<Shape> clone() const = 0;
    virtual double area() const = 0;
};

class Circle : public Shape {
    double radius_;
public:
    explicit Circle(double r) : radius_(r) {}
    std::unique_ptr<Shape> clone() const override {
        return std::make_unique<Circle>(*this);
    }
    double area() const override { return 3.14159 * radius_ * radius_; }
};

class Rectangle : public Shape {
    double w_, h_;
public:
    Rectangle(double w, double h) : w_(w), h_(h) {}
    std::unique_ptr<Shape> clone() const override {
        return std::make_unique<Rectangle>(*this);
    }
    double area() const override { return w_ * h_; }
};

Upcoming C++ User Group meetings in November 2026

The monthly overview on upcoming C++ User Group meetings! For Meeting C++ 2026 the public prerecordings have begun, join us to see some of the talks for free!

Upcoming C++ User Group meetings in November 2026

Jens Weller

From the article:

The monthly overview on upcoming C++ User Group meetings! For Meeting C++ 2026 the public prerecordings have begun, join us to see some of the talks for free!

 

C++26: Standard Library Hardening Experiments -- Bartlomiej Filipek

filipek-hardenng.pngC++26 introduces Standard Library hardening to help catch common programming errors that previously could result in undefined behaviour. This article explores how hardening works, what library operations it covers, and how today’s major compilers are implementing it.

C++26: Standard Library Hardening Experiments

by Bartlomiej Filipek

From the article:

“Hardening” seems to be a very popular term in the C++ World in 2026. In this article we’ll explore what this word means and see some core examples. Can a hardened library make C++ fully safe? Let’s find out.

The Core Idea

When you learned about std::vector you may remember that you can access an element at the i-th position using at least two expressions:

std::vector<int> v { 1, 2, 3, 4 };
v[i] = 10;     // for some i
v.at(j) = 11;  // for some j
 
The main difference between those two is that [] is unchecked (and can generate undefined behaviour if you try to access an element which is not there), while .at() may throw std::out_of_range (so it’s a well defined behaviour).

 

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

SANDOR_DARGO_ROUND.JPGC++26 introduces std::indirect, a new vocabulary type that brings value semantics to dynamically allocated objects. It offers deep copying, const propagation, and value-based comparisons without the boilerplate commonly required when using std::unique_ptr.

C++26: std::indirect

by Sandor Dargo

From the article:

C++26 adds two new vocabulary types in <memory>, introduced by P3019R14 (Coe, Peacock, Parent). From the abstract:

The class template indirect confers value-like semantics on a dynamically-allocated object. An indirect may hold an object of a class T. Copying the indirect will copy the object T. When an indirect<T> is accessed through a const access path, constness will propagate to the owned object.

The class template polymorphic confers value-like semantics on a dynamically-allocated object. A polymorphic<T> may hold an object of a class publicly derived from T. Copying the polymorphic<T> will copy the object of the derived type. When a polymorphic<T> is accessed through a const access path, constness will propagate to the owned object.

As you can tell, these two types are very close in spirit. They used to be two separate proposals — P1950 for indirect and P0201 for polymorphic — before being merged into one paper. Likewise, I originally planned to cover both in a single article, but it grew long enough that I decided to split it. This post covers std::indirect; the next one will cover std::polymorphic.

 

C++ Reflection: Verifying Compiler-generated Functions -- Lieven de Cock

logo.pngThe compiler generates special member functions as shown in Hinnant’s Table. Lieven de Cock shows how reflection can be used to verify them.

C++ Reflection: Verifying Compiler-generated Functions

by Lieven de Cock

From the article:

The compiler generates special member functions, according to specific rules. These have been described, and have been summarized in a nice table, known as Howard Hinnants’ table [Hinnant20].

Using reflection, we can verify whether this is indeed correct (which it is), refresh our knowledge of the table, and see some reflection mechanisms at work.

We will use several toy examples, each creating a struct called TestX, where X is the number of the row in the above mentioned table.

The struct contains two integer member variables and a method (doSomething()). What these do doesn’t matter, but they are needed for the reflection mechanism to be able to point out some key differences.

Used reflection mechanics

This is our starting toy structure, which is the test for row 1 in the table:

  struct Test1
  {
    int x{};
    int y{};
    
    void doSomething() {};
  };

EDG is now open source. Here’s what comes next -- Harry Bott

News about one of the four major C++ compiler front-ends:

EDG is now open source. Here’s what comes next

by Harry Bott

From the announcement:

The code is available under the Apache 2.0 license with LLVM exceptions. This permissive license allows commercial use, including incorporating EDG into proprietary products, subject to terms. For companies building C++ tools, this provides an ideal option for a front end that adapts to your needs. ...

We're excited about ways the community can make it even better. EDG has experimental support for reflection for C++26, which lets programs inspect information about types and declarations at compile time. ...

John Spicer and the EDG team led the transition. EDG’s experienced engineers are the initial maintainers, and John chairs the Fiscal Sponsorship Committee, which will include C++ veterans from the user community.

 

Implementing std::visit -- Quasar Chunawala

logo.pngLearning how to implement standard library features is illuminating. Quasar Chunawala explores implementing your own version of std::visit.

Implementing std::visit

by Quasar Chunawala

From the article:

Learning how to implement standard library features is illuminating. Quasar Chunawala explores implementing your own version of std::visit.

A variant models a choice between types. It is a smart union. Variants are sum types.

  struct on { int temperature_; };
  struct off { };

  using oven_state = std::variant<on, off>;

Recursive node-based structures, error handling, state machines etc. are examples of concepts that can be elegantly modelled by variants:

  • JSON
  • ASTs(Abstract Syntax Trees)
  • State Machines
  • Error Handling

Variant visitation

What is visitation?

Visitation can be defined as an abstraction that allows you to access the currently active variant alternative in an exhaustive and expressive manner. You are forced to provide some behaviour for all the types that the variant supports. Its expressive, because it doesn’t work through a chain of if-else; its a very elegant way of saying, for these types perform these actions.