GCC 16 Release Series: Changes, New Features, and Fixes

From the announcement:

• C++20 by default: [...] N.B. C++20 modules support is still experimental and must be enabled by -fmodules.

• Several C++26 features have been implemented:
  • P2996R13, Reflection (PR120775, enabled by -std=c++26 -freflection)
  • P3394R4, Annotations for Reflection
  • P3293R3, Splicing a base class subobject
  • P3096R12, Function Parameter Reflection
  • P3491R3, define_static_{string,object,array} (PR120783)
  • P3560R2, Error Handling in Reflection
  • P1306R5, Expansion statements (PR120776)
  • P2900R14, Contracts (PR119061)
  • P2795R5, Erroneous behavior for uninitialized reads (PR114457)
  • [...]

• Improved experimental C++20 modules support:
  • New command line option --compile-std-module that conveniently builds the <bits/stdc++.h> header unit and the std and std.compat modules before compiling any source files explicitly specified on the command line.
  • Whenever the <bits/stdc++.h> header unit has been built, GCC now transparently translates an #include of any importable standard library header into an import of <bits/stdc++.h>.
  • Many reported bugs have been fixed, thanks to Nathaniel Shead.
  • [...]

Runtime Library (libstdc++)

• [...]
• Improved experimental support for [...]
  • std::mdspan, thanks to Luc Grosheintz.
  • [...]
  • std::simd.
  • std::inplace_vector.
  • [...]

Glaze 7.2 - C++26 Reflection | YAML, CBOR, MessagePack, TOML and more

From the article:

Glaze now supports C++26 reflection with experimental GCC and Clang compilers. GCC 16 will soon be released with this support. When enabled, Glaze replaces the traditional __PRETTY_FUNCTION__ parsing and structured binding tricks with proper compile-time reflection primitives (std::meta).

The API doesn't change at all. You just get much more powerful automatic reflection that still works with Glaze overrides! Glaze was designed with automatic reflection in mind and still lets you customize reflection metadata using glz::meta on top of what std::meta provides via defaults.

The Wonderful World of Designing a USB Stack Using Modern C++

by Madeline Schneider

Summary of the talk:

Have you ever wondered how to design a library to abstract and manage complex communication protocols like USB? Have you ever wondered which parts of a protocol need to be hardware abstractions and which parts are hardware agnostic? Well you’re in luck, my mentor and I have designed a USB stack from the ground up in modern C++! We found that the public offerings did not meet our needs. Our requirements are:

• Resource efficient
• Portable
• Modular
• Convenient to use
• Distributable via single pre-built binary using conan
• Without allocations after initialization

In this talk you’ll learn the basics of how USB works at the lowest level from a software perspective. You’ll learn why malleability and freedom are so important for USB device development and how C++ makes such a library design easy to implement. Embark with me on a deep-dive into shaping a library where complexity runs wild. This talk will have lessons on library and API design in situations where the degrees of freedom are vast and all parts must magically fit together. By the end, you’ll carry away practical patterns for taming vast design spaces—skills that apply to any ambitious library, far beyond USB.

Can Standard C++ Replace CUDA for GPU Acceleration?

by Elmar Westphal

Summary of the talk:

On top of the woes of multi-threaded programming itself, coding for GPUs used to be about dealing with kernels, separate memory domains, warps, blocks and other strange things. Later, life became easier and you could sprinkle in a bunch of pragmas, hoping that your favorite language extension would deal with all of this for you, and better memory model abstractions came up that were less painful to deal with. In recent years, new drivers (seemingly) levelled the boundaries between memory domains and new compilers allow us to deploy code to the GPU using standard C++ execution policies. The performance of the generated code is often similar to that of its CUDA-C++ counterpart. Of course there is no magic bullet to shoot at your (legacy) code and there are caveats, but come and see how using standard parallelism (also) for programming GPUs makes it a lot easier to write portable and more future-proof high-performance C++ code.

Behold the power of meta::substitute

by Barry Revzin

From the article:

Over winter break, I started working on proposal for string interpolation. It was a lot of fun to work through implementing, basically an hour a day during my daughter’s nap time. The design itself is motivated by wanting to have a lot more functionality other than just formatting — and one of the examples in the paper was implementing an algorithm that does highlighting of the interpolations, such that:

 

 

 

would print this:

x=5 and y=*10* and z=hello!

without doing any additional parsing work. I got the example from Vittorio Romeo’s original paper.

Now, when I wrote the paper, I considered this to be a simple example demonstrating something that was possible with the design I was proposing that was not possible with the other design. I thought that because obviously you need the format string as a compile-time constant in order to parse it at compile time to get the information that you need.

The annual global C++ developer survey is now open:

2026 Annual C++ Developer Survey "Lite"

Please share your feedback in this annual 10-minute survey to help inform C++ standardization and C++ tool vendors. This is the biggest opportunity we all have each year to make our voices heard and help improve our industry and community!

A summary of the results, including aggregated highlights of common answers in the write-in responses, will be posted publicly here on isocpp.org and shared with the C++ standardization committee participants and C++ tool vendors to help inform C++ evolution and tooling.

The survey closes in one week.

Thank you for participating and helping to inform our committee and community.

C++: Some Assembly Required

by Matt Godbolt

Summary of the talk:

Join Matt in exploring how the C++ ecosystem has evolved through the interplay of intentional design and emergent collaboration. Standards committees craft language features and compiler teams implement them, but something amazing happens in the spaces between: tools appear, communities form, and solutions emerge that nobody quite planned for. What started as individual developers solving their own problems has grown into an interconnected ecosystem that shapes how we all write C++.

From documentation to testing, from build systems to package managers, we'll examine how the C++ community has assembled itself around shared pain points and accidental standards. Using examples and perhaps too many rainforest metaphors, this talk celebrates not just the language we've built, but the organic ecosystem that's grown up around it. Come discover why C++'s greatest strength might be that it's always required some assembly.

How C++ Finally Beats Rust at JSON Serialization

by Daniel Lemire & Francisco Geiman Thiesen

Summary of the talk:

JSON, or JavaScript Object Notation, has become a cornerstone for storing and exchanging data. Its appeal lies in its simplicity—human-readable text that elegantly captures structured data through attribute-value pairs and arrays: {"age": 5, "name": "Daniel", "toys": ["wooden dog", "little car"]}. JSON is intuitive yet powerful. But ingesting and producing JSON can turn into a performance choke point. In C++, it can be a tedious, error-prone task. Programmers wrestle with unexpected content, manually mapping data to and from native structures, all while striving for speed and safety.

With languages like Java, C#, Zig, Rust, or Python, JSON serialization and deserialization typically requires far less work. In particular, Rust's serde library blends convenience with high speed. We wish for a C++ library to automatically handle JSON production and consumption, seamlessly tied to native data structures. It is not merely to simplify life for developers; it is also about crafting code that is both fast and solid, generated at compile time by a battle-tested library.

Thankfully, C++ might soon be getting reflective metaprogramming (  PR2996  ). Leveraging the  experimental Bloomberg LLVM fork  with reflective metaprogramming, we have built a full-fledged implementation—complete with tests, benchmarks, and documentation. Our goal is to have production-ready code the moment mainstream compilers catch up. The results speak for themselves: we are parsing JSON directly into C++ structures at gigabytes per second, outpacing even mature heavyweights like Rust's serde. Better yet, the conversion between C++ data structures and JSON is fully automated, thanks to metaprogramming. It has the potential to be a leap forward for C++ in the data-driven age. Unfortunately, there are still problems and limitations: we present them and provide some solutions.

Devirtualization and Static Polymorphism

by David Álvarez Rosa

From the article:

Ever wondered why your “clean” polymorphic design underperforms in benchmarks? Virtual dispatch enables polymorphism, but it comes with hidden overhead: pointer indirection, larger object layouts, and fewer inlining opportunities.

Compilers do their best to devirtualize these calls, but it isn’t always possible. On latency-sensitive paths, it’s beneficial to manually replace dynamic dispatch with static polymorphism, so calls are resolved at compile time and the abstraction has effectively zero runtime cost.

Why Every C++ Game Developer Should Learn SDL 3 Now

by Mike Shah

Summary of the talk:

The C++ programming language does not have a standard graphics library, However, there exists many popular graphics frameworks for cross-platform graphics. In this talk, I will provide an introduction to the Simple Directmedia Layer (SDL) library, which has at the start of 2025 released version 3. This library for several decades has been a standard in the games and graphics industry. Throughout this talk, I will show how to get started with the library, some more advanced examples (including compiling graphics applications to web), and then talk about what a standard graphics library could look like in C++, or if it is even necessary. I will also talk about the 3D GPU library in SDL3. Attendees will leave this talk ready to build multimedia / game applications and with an understanding on if SDL3 is the right tool for them.

Like all software, the site requires maintenance. It has been in read-only mode for some time while Nate has been leading the work to migrate it to MediaWiki. Because the Standard C++ Foundation's web wizard, James Riordon, recently migrated the ISO C++ committee wiki (now also maintained by the Foundation) to MediaWiki, I asked Nate whether the Foundation and James could help. Nate accepted our offer, and thanks to Nate and James's work, cppreference is now almost ready to return to normal read-write operation.

To help keep the site running smoothly going forward, the Foundation plans to continue providing hosting and administrative support for the site's infrastructure, including future MediaWiki and related updates. That should let Nate stay focused on leading the site's content and coordinating the volunteer editors who keep cppreference current.

We expect the refreshed site, including support for all languages, to return to read-write mode later this month. Fingers crossed. My thanks again to Nate, James, and everyone who has helped make cppreference the indispensable reference it is today, and to everyone for their patience while this necessary maintenance has been underway.

Cheers,

Herb

Implementing Your Own C++ Atomics

by Ben Saks

Summary of the talk:

Atomic objects are extremely useful for concurrent programming. Unfortunately, some embedded toolchains like AVR-GCC omit portions of the C++ Standard Library, including headers like ＜atomic＞ .This makes it much harder to program concurrent software on these platforms, since many tutorials and open-source libraries assume Standard Library support. For example, these talks from past CppCons present lock-free data structures and algorithms that rely strongly on lock-free instantiations of std::atomic＜T＞:

Single Producer Single Consumer Lock-free FIFO From the Ground Up – Charles Frasch – CppCon 2023
Introduction to Wait-free Algorithms in C++ Programming – Daniel Anderson – CppCon 2024
User API & C++ Implementation of a Multi Producer, Multi Consumer, Lock Free, Atomic Queue – Erez Strauss – CppCon 2024

This session will show you how to implement your own atomic types in the absence of library support. These atomic types can greatly expand the number of tutorials and open-source libraries available for you to use. A clear understanding of how atomic types are implemented will also help you use objects of those types more effectively on platforms that do provide native support.

Power of C++26 Reflection: Strong (opaque) type definitions 

From the article:

With reflection, you can easily create "opaque" type definitions, i.e "strong types". It works by having an inner value stored, and wrapping over all public member functions.

Note: I am using queue_injection { ... } with the EDG experimental reflection, which afaik wasn't actually integrated into the C++26 standard, but without it you would simply need two build stages for codegen. This is also just a proof of concept, some features aren't fully developed (e.g aggregate initialization)

struct Item { /* ... */ }; // name, price as methods

struct FoodItem;
struct BookItem;
struct MovieItem;

consteval { 
    make_strong_typedef(^^FoodItem, ^^Item); 
    make_strong_typedef(^^BookItem, ^^Item); 
    make_strong_typedef(^^MovieItem, ^^Item); 
}

// Fully distinct types
void display(FoodItem &i) {
    std::cout << "Food: " << i.name() << ", " << i.price() << std::endl;
}
void display(BookItem &i) {
    std::cout << "Book: " << i.name() << ", " << i.price() << std::endl;
}

int main() {
    FoodItem fi("apple", 10); // works if Item constructor isn't marked explicit
    FoodItem fi_conversion(Item{"chocolate", 5}); // otherwise
    BookItem bi("the art of war", 20);
    MovieItem mi("interstellar", 25);

    display(fi);
    display(bi);
    // display(Item{"hello", 1}); // incorrect, missing display(Item&) function
    // display(mi); // incorrect, missing display(MovieItem&) function
}

Back to Basics: Custom Allocators Explained - From Basics to Advanced

by Kevin Carpenter

Summary of the talk:

Effective memory management is crucial for building efficient and reliable C++ applications. Custom memory allocators provide a powerful tool for optimizing memory usage, reducing fragmentation, and improving performance. This talk will explore the intricacies of memory allocation in C++, from the basics of dynamic memory management to the implementation of custom allocators. Attendees will gain insights into the standard allocator model, techniques for designing custom allocators, and practical examples of their use in real-world applications.

Join us to unlock the full potential of memory management in your C++ projects.

Cache Me Maybe: The Performance Secret Every C++ Developer Needs

by Michelle D'Souza

Summary of the talk:

Calling all code detectives! Grab your trench coats and magnifying glasses ... it's time to crack the case of sluggish C++ performance. In this thrilling investigation, we'll uncover the hidden world of your computer's built-in cache and how to harness it to turbocharge your code.

We'll comb through the fundamentals of caches like seasoned sleuths, uncover clues on optimizing access patterns, and interrogate suspects like false sharing and cache unfriendly data structures. We will also examine benchmark evidence based on real-world production code, exposing how each technique delivers the goods.

By the end of this mission, you'll be armed with a detective's toolkit of cache savvy strategies, ready to solve cross-platform performance mysteries and bring blazing fast code to justice. Cache you at this session, maybe!

std::vector — Four Mechanisms Behind Every push_back()

by Gracjan Olbinski

From the article:

"You call push_back() a thousand times. The vector reallocates about ten. Behind that simple interface, four mechanisms are working together — each one invisible during normal use, each one shaping your performance in ways that push_back() will never tell you about."

Matrix Multiplication Deep Dive || Cache Blocking, SIMD & Parallelization

by Aliaksei Sala

Summary of the talk:

Matrix multiplication is a fundamental operation in scientific computing, game development, AI, and numerous high-performance applications. While its mathematical definition is simple, achieving optimal performance in C++ is far from trivial.

In this talk, we will explore different optimization techniques for matrix multiplication, from naive implementations to highly tuned versions leveraging modern hardware features. We will cover key performance-enhancing strategies such as loop unrolling, cache blocking, SIMD vectorization, parallelization using threads and more. Through benchmarking and profiling, we will measure the real impact of these optimizations.

By the end of this session, attendees will gain insights into two critical questions:

How hard is it to implement an optimized matrix multiplication in C++? How effective is C++ for achieving peak performance in this task?

This talk is suitable for developers interested in performance optimization, computational efficiency, and modern C++ techniques for numerical computing.

In this article, we'll perform some early compilation time benchmarks of one of the most awaited C++26 features.

The hidden compile-time cost of C++26 reflection

by Vittorio Romeo

From the article:

Fast compilation times are extremely valuable to keep iteration times low, productivity and motivation high, and to quickly see the impact of your changes.

I would love to see a world where C++26 reflection is as close as possible to a lightweight language feature [...]

So, I decided to take some early measurements.

Stop Choosing: Get C++ Performance in Python Algos with C++26

by Richard Hickling

From the article:

The “religious war” between Python and C++ in algorithmic trading usually boils down to a single trade-off: Python is faster for getting ideas to market, while C++ is faster for getting orders into the book.

But why choose? With the advent of C++26 Reflection, you can now have the flexibility of a Python-based strategy without the performance penalty of slow loops.

Bring in C++ Rapidly: How Reflection Works

The biggest hurdle in hybrid trading systems has always been the “bridge.” Traditionally, if you wrote a complex pricer in C++, you had to manually write “boilerplate” code to tell Python how to talk to it. If you added a new function, you had to update the bridge. It was tedious and error-prone.

Reflection changes the game by allowing the code to “look in the mirror”. Instead of you manually describing your C++ functions to Python, the compiler does it for you. It programmatically inspects your classes and generates the bindings automatically.

Practical Reflection With C++26

by Barry Revzin

Summary of the talk:

With the adoption of Reflection for C++26, the landscape of what is possible has shifted. This talk will focus on implementing Struct-of-Arrays for an arbitrary aggregate, but will also take some detours to cover some techniques that will prove useful for solving a wide range of problems.

A Brief History of Bjarne Stroustrup, the Creator of C++

by CultRepo

Watch now:

<iframe width="560" height="315" src="https://www.youtube.com/embed/uDtvEsv730Y?si=QD_WmemwpsAfNsVI" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>

Announcing Meeting C++ 2026

by Jens Weller

From the article:

We'll be meeting from the 26th - 28th November in Berlin! You have the unique chance to spend the 1st advent in Berlin with C++ and Christmas Markets open!

With Mateusz Pusz and Kate Gregory I've chosen two well known speakers for the keynotes this year. Mateusz is well known for his units library, which currently also is proposed for the standard. It is also an important contribution to making C++ more safe and secure, the big topic of last year. Then Kate Gregory will be visiting us in Berlin again, she is known for her ability to create great talks around technical and social aspects in our daily lives as devs. You might remember her from giving a keynote in 2017, or speaking about the aging programmer two years ago.

For the 15th time Meeting C++ will organize a great event for 3 days filled with lots of content about C++, like last year the plan is to host 3 tracks in parallel in Berlin, with an optional 4th track. The 4th track will be unlocked either by sponsorships or ticket sales. You can be a part of this great C++ event by attending onsite and online. There is already great news for onsite attendees: Hudson River Trading is again this years t-shirt sponsor, a great and unique Meeting C++ 2026 t-shirt is an exclusive perk for onsite attendees!

Threads vs Coroutines: Why C++ Has Two Concurrency Models

by Conor Spilsbury

Summary of the talk:

The C++11 standard introduced a powerful set of tools for concurrency such as threads, mutexes, condition variables, and futures. More recently, C++20 introduced another powerful but fundamentally different concurrency abstraction in the form of coroutines. But coroutines are not just an evolution or a replacement for threads. Instead, they each solve different problems in different ways. Choosing the right tool for the job requires understanding how each works under the hood and where they shine. This talk will help build that intuition by looking at how each interacts with the operating system and hardware which will help make better decisions when choosing which to use.

We'll explore how threads and synchronization primitives work at the operating-system and hardware level, from thread creation and scheduling to where context switching and synchronization introduce performance costs. We’ll then contrast this to the coroutine model introduced in C++20 which takes a fundamentally different approach by using a cooperative model based on the suspension and resumption of work.

Given this understanding, we’ll finish by applying this intuition to a set of real-world scenarios to identify whether threads or coroutines are a better fit for the problem at hand.

C++26: std::is_within_lifetime

by Sandor Dargo

From the article:

When I was looking for the next topic for my posts, my eyes stopped on std::is_within_lifetime. Dealing with lifetime issues is a quite common source of bugs, after all. Then I clicked on the link and I read Checking if a union alternative is active. I scratched my head. Is the link correct?

It is — and it totally makes sense.

Let’s get into the details and first check what P2641R4 is about.

What does std::is_within_lifetime do?

C++26 adds bool std::is_within_lifetime(const T* p) to the <type_traits> header. This function checks whether p points to an object that is currently within its lifetime during constant evaluation.

CppCon 2025 More Speed & Simplicity: Practical Data-Oriented Design in C++

by Vittorio Romeo

Summary of the talk:

Data-Oriented Design (DOD) presents a different way of thinking: prioritizing data layout not only unlocks significant performance gains via cache efficiency but can also lead to surprising simplicity in the code that actually processes the data.

This talk is a practical introduction for C++ developers familiar with OOP. Through a step-by-step refactoring of a conventional OOP design, we’ll both cover how data access patterns influence speed and how a data-first approach can clarify intent.

We’ll measure the performance impact with benchmarks and analyze how the refactored code, particularly the data processing loops, can become more direct and conceptually simpler.

Key techniques like Structure-of-Arrays (SoA) vs. Array-of-Structures (AoS) will be explained and benchmarked, considering their effects on both execution time and code clarity. We’ll pragmatically weigh the strengths (performance, simpler data logic) and weaknesses of DOD, highlighting how it can complement, not just replace, OOP.

We’ll also demonstrate that DOD doesn’t necessitate abandoning robust abstractions, showcasing C++ techniques for creating safe, expressive APIs that manage both complexity and performance.

Let’s learn how thinking “data-first” can make your C++ code faster and easier to reason about!

The cost of a function call

by Daniel Lemire

From the article:

When programming, we chain functions together. Function A calls function B. And so forth.

You do not have to program this way, you could write an entire program using a single function. It would be a fun exercise to write a non-trivial program using a single function… as long as you delegate the code writing to AI because human beings quickly struggle with long functions.

A key compiler optimization is ‘inlining’: the compiler takes your function definition and it tries to substitute it at the call location. It is conceptually quite simple. Consider the following example where the function add3 calls the function add.

int add(int x, int y) { 
     return x + y; 
} 
int add3(int x, int y, int z) { 
     return add(add(x, y), z); 
} 

You can manually inline the call as follows.

int add3(int x, int y, int z) { 
     return x + y + z; 
}

Implementing vector<T>

by Quasar Chunawala

From the article:

The most fundamental STL data-structure is the vector. In this article, I am going to explore writing a custom implementation of the vector data-structure. The standard library implementation std::vector is a work of art, it is extremely efficient at managing memory and has been tested ad nauseam. It is much better, in fact, than a homegrown alternative would be.

Why then write our own custom vector?

• Writing a naive implementation is challenging and rewarding. It is a lot of fun!
• Coding up these training implementations, thinking about corner cases, getting your code reviewed, revisiting your design is very effective at understanding the inner workings of STL data-structures and writing good C++ code.
• Its a good opportunity to learn about low-level memory management algorithms.

We are not aiming for an exhaustive representation or implementation, but we will write test cases for all basic functionalities expected out of a vector-like data-structure.

Informally, a std::vector<T> represents a dynamically allocated array that can grow as needed. As with any array, a std::vector<T> is a sequence of elements of type T arranged contiguously in memory. We will put our homegrown version of vector<T> under the dev namespace.

Flavours of Reflection: Comparing C++26 reflection with similar capabilities in other programming languages

by Bernard Teo

From the article:

Reflection is imminent. It is set to be part of C++26, and it is perhaps the most anticipated feature accepted into this version of the standard. Lots of implementation work has already been done for Clang and GCC — they pretty much already work (both are on Compiler Explorer), and it hopefully won’t be too long before they get merged into their respective compilers.

Many programming languages already provide some reflection capabilities, so some people may think that C++ is simply playing catch-up. However, C++’s reflection feature does differ in important ways. This blog post explores the existing reflection capabilities of Python, Java, C#, and Rust, comparing them with one another as well as with the flavour of reflection slated for C++26.

In the rest of this blog post, the knowledge of C++ fundamentals is assumed (but not for the other programming languages, where non-commonsensical code will be explained).

 

IIFE for Complex Initialization

by Bartlomiej Filipek

In this article:

I hope you’re initializing most variables as const (so that the code is more explicit, and also compiler can reason better about the code and optimize).

For example, it’s easy to write:

const int myParam = inputParam * 10 + 5; 

or even:

const int myParam = bCondition ? inputParam*2 : inputParam + 10; 

But what about complex expressions? When we have to use several lines of code, or when the ? operator is not sufficient.

‘It’s easy’ you say: you can wrap that initialization into a separate function.

While that’s the right answer in most cases, I’ve noticed that in reality a lot of people write code in the current scope. That forces you to stop using const and code is a bit uglier.

Range adaptors - 5 years after C++20

by Hannes Hauswedell

Watch now:

<iframe allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen="" frameborder="0" height="315" referrerpolicy="strict-origin-when-cross-origin" src="https://www.youtube-nocookie.com/embed/nficAvk5RA4?si=w86EVk7oX89uVcPg" title="YouTube video player" width="560"></iframe>

So how do you quickly concatenate strings?

By Aleksandr Orefkov

From the article:

All practicing programmers have to concatenate strings. Precisely concatenate, we don’t have some JavaScript or PHP, in C++ we have this fancy word for it. Programmers in other languages ​​simply “add” strings together without much thought, without even thinking about this operation. After all, what could be simpler than

return "The answer is " + str_answer + ", count is " + count;

But while it’s forgivable for script kiddies not to think about the meaning behind such a simple notation, it’s unacceptable for an experienced developer to approach such an important issue so irresponsibly. An experienced developer, imagining such C++ code, immediately sees the terrifying abyss of problems that such an approach can create.

What type is str_answer? What type is count? “The answer is “ and “, count is “ - are literals that add to std::string as a const char*. So, strlen will be called. I wonder if the compiler will be able to optimize and calculate their length at compile time? Oh well, it seems like constexpr is in the addition, let’s hope so.
This is the first level of problems for now. And let’s say we successfully solved them, creating the following code:

std::string make_answer(std::string_view str_answer, int count) {
    return "The answer is " + std::string{str_answer}
        + ", count is " + std::to_string(count);
}

It sounds like “Hurray!”, but it’s somehow not loud enough…

15 Different Ways to Filter Containers in Modern C++

by Bartłomiej Filipek

From the article:

Do you know how many ways we can implement a filter function in C++? While the problem is relatively easy to understand – take a container, copy elements that match a predicate and the return a new container – it’s good to exercise with the C++ Standard Library and check a few ideas. We can also apply some modern C++ techniques, including C++23. Let’s start!

The problem statement

To be precise by a filter, I mean a function with the following interface:

  auto Filter(const Container& cont,
              UnaryPredicate p) {}

It takes a container and a predicate, and then it creates an output container with elements that satisfy the predicate. We can use it like the following:

  const std::vector<std::string> vec{
    "Hello", "**txt", "World", "error", "warning",
    "C++", "****" };
  auto filtered = Filter(vec, [](auto& elem) {
    return !elem.starts_with('*'); });
    // filtered should have "Hello", "World",
    // "error", "warning", "C++"

Writing such a function can be a good exercise with various options and algorithms in the Standard Library. What’s more, our function hides internal things like iterators, so it’s more like a range-based version.

Coroutines – A Deep Dive

by Quasar Chunawala

From the article:

Following on from the introduction in the editorial, let’s understand the basic mechanics needed to code up a simple coroutine, and I’ll show you how to yield from the coroutine and await results.

The simplest coroutine

The following code is the simplest implementation of a coroutine:

  #include <coroutine>
  void coro_func(){
    co_return;
  }
  int main(){
    coro_func();
  }

Our first coroutine will just return nothing. It will not do anything else. Sadly, the preceding code is too simple for a functional coroutine and it will not compile. When compiling with gcc 15.2, we get the error shown in Figure 1.

<source>: In function 'void coro_func()': <source>:4:5: error: unable to find the promise type for this coroutine 4 | co_return; | ^~~~~~~~~

Looking at C++ reference, we see that the return type of a coroutine must define a type named promise_type. Why do we need a promise? The promise_type is the second important piece in the coroutine mechanism. We can draw an analogy from futures and promises which are essential blocks for achieving asynchronous programming in C++. The future is the thing, that the function that does the asynchronous computation, hands out back to the caller, that the caller can use to retrieve the result by invoking the get() member function. The future has the role of the return object. 

Concurrency Flavours

by Lucian Radu Teodorescu

From the article:

Most engineers today use concurrency – often without a clear understanding of what it is, why it’s needed, or which flavour they’re dealing with. The vocabulary around concurrency is rich but muddled. Terms like parallelism, multithreading, asynchrony, reactive programming, and structured concurrency are regularly conflated – even in technical discussions.

This confusion isn’t just semantic – it leads to real-world consequences. If the goal behind using concurrency is unclear, the result is often poor concurrency – brittle code, wasted resources, or systems that are needlessly hard to reason about. Choosing the right concurrency strategy requires more than knowing a framework or following a pattern – it requires understanding what kind of complexity you’re introducing, and why.

To help clarify this complexity, the article aims to map out some of the main flavours of concurrency. Rather than defining terms rigidly, we’ll explore the motivations behind them – and the distinct mindsets they evoke. While this article includes a few C++ code examples (using features to be added in C++26), its focus is conceptual – distinguishing between the flavours of concurrency. Our goal is to refine the reader’s taste for concurrency.

Exclusive state access, I

by Andrzej Krzemieński

From the article:

Value semantics is a way of organizing your programs, which C++ supports and endorses. Its key characteristics in a nutshell:

1. Throughout its lifetime an object (via its type and special member functions) is used to represent a value.
2. Different parts of the program communicate values via objects. While the value matters, objects themselves (their address, their sizeof) do not.
3. Object’s value is isolated from other objects’ values.

This begs the question, what is value, but we will not answer it. First, because it is difficult, and maybe impossible. It is pretty clear what value objects of type int represent. It is fairly uncontroversial what value is represented by vector<int>, once we accept that the value representation need not fit into the sizeof of the object, but can spread across other memory locations and resources, and that vector’s capacity is not part of this value, even though it is part of its state. But there are things like std::mutex where naming the value is tricky.

Singleton done right in C++

by Andreas Fertig

From the article:

Let's use a usage pattern for a singleton that I see frequently, a system-wide logger. A simple implementation can look like the following code:

class Logger {
  Logger() = default;

public:
  static Logger& Instance()
  {
    static Logger theOneAndOnlyLogger{};

    return theOneAndOnlyLogger;
  }

  void Info(std::string_view msg) { std::print("Info: {}", msg); }
  void Error(std::string_view msg) { std::print("Error: {}", msg); }
};

The key parts for a singleton in C++ are that the constructor is private and an access function that is static. With that, you ensure that a singleton object, here Logger can only be constructed by calling Instance, essentially limiting the number of Logger objects to a single one.

You're using such a Logger like this:

Logger::Instance().Info("A test");

Templates and metaprogramming considered as the big bad wolf of C++, and it’s time to stop being scared of this wolf, as it’s one of the most powerful creatures of C++.

Talk: Who’s Afraid of the Big Bad Template

by Coral Kashri

From the description:

In this talk I’ve demonstrated the power of this incredible creature, while I hope that this talk would be an easy enterence to this concept (pan intended), and to help you developing the anticipation to walk into the cave of metaprogramming.

The talk was give on Core C++ 2025.

Templates and metaprogramming considered as the big bad wolf of C++, and it’s time to stop being scared of this wolf, as it’s one of the most powerful creatures of C++.

Talk: Who’s Afraid of the Big Bad Template

by Coral Kashri

From the description:

In this talk I’ve demonstrated the power of this incredible creature, while I hope that this talk would be an easy enterence to this concept (pan intended), and to help you developing the anticipation to walk into the cave of metaprogramming.

The talk was give on Core C++ 2025.

2025, A Year of Conferences

by Sandor Dargo

From the article:

This year I had the chance to attend three conferences onsite, plus one online, and even a meetup in my hometown, Budapest. Depending on who you ask, maybe it’s not a lot — I know some speakers do twice as many. But if you ask my family, you’d probably get a different (and understandable) answer. For me — for us — it’s a lot. It’s also an honour and a privilege in many ways.

To express my appreciation and gratitude toward the organizers and the community, I do two things:

• I try to prepare well for my talks.
• I post trip reports soon after each event — usually within a week.

Those trip reports are moderately personal: I share which talks I liked and also some of my impressions, but I try to make them useful rather than purely personal. Still, I think that once in a while, a more personal, less serious post has its place — and that’s what this one wanted to be originally.

At one of the social dinners at CppCon, a developer working for a FAANG company in New York asked me which conference I’d recommend. My answer: it depends on your goals — and your budget and constraints.

 

A Guest Editorial

by Quasar Chunawala, Frances Buontempo

From the article:

You’ve likely heard about this new C++20 feature, coroutines. I think that this is a really important subject and there are several cool use-cases for coroutines. A coroutine in the simplest terms is just a function that you can pause in the middle. At a later point the caller will decide to resume the execution of the function right where you left off. Unlike a function therefore, coroutines are always stateful - you at least need to remember where you left off in the function body.

Coroutines can simplify our code! Coroutines are a great tool, when it comes to implementing parsers.

The coroutine return type

The initial call to the coroutine function will produce a return object of a certain ReturnType and hand it back to the caller. The interface of this type is what is going to determine what the coroutine is capable of. Since coroutines are super-flexible, we can do a whole lot with this return object. If you have some coroutine, and you want to understand what it’s doing, the first thing you should look at is the ReturnType, and what it’s interface is. The important thing here is, we design this ReturnType. If you are writing a coroutine, you can decide what goes into this interface.

15 Different Ways to Filter Containers in Modern C++

by Bartłomiej Filipek

From the article:

Do you know how many ways we can implement a filter function in C++? While the problem is relatively easy to understand – take a container, copy elements that match a predicate and the return a new container – it’s good to exercise with the C++ Standard Library and check a few ideas. We can also apply some modern C++ techniques, including C++23. Let’s start!

The problem statement

To be precise by a filter, I mean a function with the following interface:

  auto Filter(const Container& cont,
              UnaryPredicate p) {}

It takes a container and a predicate, and then it creates an output container with elements that satisfy the predicate. We can use it like the following:

  const std::vector<std::string> vec{
    "Hello", "**txt", "World", "error", "warning",
    "C++", "****" };
  auto filtered = Filter(vec, [](auto& elem) {
    return !elem.starts_with('*'); });
    // filtered should have "Hello", "World",
    // "error", "warning", "C++"

Writing such a function can be a good exercise with various options and algorithms in the Standard Library. What’s more, our function hides internal things like iterators, so it’s more like a range-based version.

Time in C++: std::chrono::high_resolution_clock - Myths and Realities

by Sandor Dargo

From the article:

If there’s one clock in <chrono> that causes the most confusion, it’s std::chrono::high_resolution_clock. The name sounds too tempting — who wouldn’t want “the highest resolution”? But like many things in C++, the details matter.

In the earlier parts of this series, we looked at system_clock as the wall-clock time source, and at steady_clock as the reliable choice for measuring intervals. This time, we’ll tackle the so-called “high-resolution” clock, separate fact from myth, and see why it’s not always the right choice — even when you think you need precision.

What “high resolution” actually means

A clock’s resolution (or precision) is the granularity of its tick period — i.e., the smallest representable step in time for that clock’s time_point. In <chrono> it’s exposed via Clock::period, a std::ratio.

Notice an important difference. I didn’t mention accuracy, only precision. A clock might represent nanoseconds, but still be inaccurate due to hardware or OS scheduling. A higher resolution doesn’t necessarily mean better measurement. For timing, stability and monotonicity matter much more than how fine-grained the tick is.

Coroutines – A Deep Dive

by Quasar Chunawala

From the article:

The following code is the simplest implementation of a coroutine:

  #include <coroutine>
  void coro_func(){
    co_return;
  }
  int main(){
    coro_func();
  }

Our first coroutine will just return nothing. It will not do anything else. Sadly, the preceding code is too simple for a functional coroutine and it will not compile. When compiling with gcc 15.2, we get the error shown in Figure 1.

<source>: In function 'void coro_func()': <source>:4:5: error: unable to find the promise type for this coroutine 4 | co_return; | ^~~~~~~~~

Figure 1

Looking at C++ reference, we see that the return type of a coroutine must define a type named promise_type.

Concurrency Flavours

by Lucian Radu Teodorescu

From the article:

Most engineers today use concurrency – often without a clear understanding of what it is, why it’s needed, or which flavour they’re dealing with. The vocabulary around concurrency is rich but muddled. Terms like parallelism, multithreading, asynchrony, reactive programming, and structured concurrency are regularly conflated – even in technical discussions.

This confusion isn’t just semantic – it leads to real-world consequences. If the goal behind using concurrency is unclear, the result is often poor concurrency – brittle code, wasted resources, or systems that are needlessly hard to reason about. Choosing the right concurrency strategy requires more than knowing a framework or following a pattern – it requires understanding what kind of complexity you’re introducing, and why.

To help clarify this complexity, the article aims to map out some of the main flavours of concurrency. Rather than defining terms rigidly, we’ll explore the motivations behind them – and the distinct mindsets they evoke. While this article includes a few C++ code examples (using features to be added in C++26), its focus is conceptual – distinguishing between the flavours of concurrency. Our goal is to refine the reader’s taste for concurrency.

Finding the Next Unicode Code Point in Strings: UTF-8 vs. UTF-16

by Giovanni Dicanio

From the article:

Both UTF-16 and UTF-8 are variable-length encodings. In particular, UTF-8 encodes each valid Unicode code point using one to four 8-bit byte units. On the other hand, UTF-16 is somewhat simpler: In fact, Unicode code points are encoded in UTF-16 using just one or two 16-bit code units.

(...) The functions have the following prototypes:

// Returns the next Unicode code point and number of bytes consumed.
// Throws std::out_of_range if index is out of bounds or string ends prematurely.
// Throws std::invalid_argument on invalid UTF-8 sequence.
[[nodiscard]] std::pair<char32_t, size_t> NextCodePointUtf8(
    const std::string& str,
    size_t index
);

// Returns the next Unicode code point and the number of UTF-16 code units consumed.
// Throws std::out_of_range if index is out of bounds or string ends prematurely.
// Throws std::invalid_argument on invalid UTF-16 sequence.
[[nodiscard]] std::pair<char32_t, size_t> NextCodePointUtf16(
    const std::wstring& input,
    size_t index
);

Practical Security in Production: Hardening the C++ Standard Library at massive scale

by Louis Dionne, Alex Rebert, Max Shavrick, and Konstantin Varlamov

From the article:

Over the past few years there has been a lot of talk about memory-safety vulnerabilities, and rightly so—attackers continue to take advantage of them to achieve their objectives. Aside from security, memory unsafety can be the cause of reliability issues and is notoriously expensive to debug. Considering the billions of lines of C++ code in production today, we need to do what we can to make C++ measurably safer over the next few years with as low of an adoption barrier as possible.

In 2019, Alex Gaynor, a security expert and one of the leading voices in memory safety, wrote a piece titled "Modern C++ Won't Save Us," where he gave examples of foundational types such as std::optional that were unsafe in the idiomatic use cases. What happens when these unsafe types are used beyond their contract? Well, you guessed it: undefined behavior. The std::optional type isn't the only one to behave like this. If you look at how this compares with modern languages, you can see that C++ is the outlier.

So, what's to be done? Possibly one of the best places to start today is by improving our standard libraries. They provide the baseline "vocabulary types" for developers—and if they're not safe, it will be tough to build safety around them. The std::optional type is only one of many vocabulary types in the C++ Standard Library that aren't safe by default today. Given the current state, it seems mostly clear that the first step should be hardening our standard library, and in our case, this was LLVM's libc++.

Qt completes the recommended public cash offer to the shareholders of I.A.R. Systems Group

From the article:

On 4 July 2025, Qt Group Plc's ("Qt Group") wholly owned subsidiary The Qt Company Ltd ("The Qt Company" and together with Qt Group, "Qt"), announced a recommended public cash offer to the shareholders of class B shares (the "Shares" or, individually, a "Share") in I.A.R. Systems Group AB (publ) ("IAR"), to tender all their Shares at a price of SEK 180 in cash per Share (the "Offer"). The Shares in IAR are traded on Nasdaq Stockholm, Mid Cap. An offer document relating to the Offer was published on 15 August 2025.

At the end of the acceptance period on 10 October 2025, the Offer had been accepted by shareholders with a total of 12,037,848 Shares in IAR, corresponding to 94.49 per cent of the outstanding shares and votes in IAR.[1] As a result, The Qt Company controls in total 12,037,848 Shares in IAR, corresponding to 94.49 per cent of the outstanding shares and votes in IAR.[2]

The Qt Company has decided to complete the Offer. All conditions are satisfied or have been waived. Settlement for Shares tendered in the Offer during the initial acceptance period will be initiated on or around 17 October 2025.

 

A little Introduction to Control Flow Integrity - James McNellis - Keynote Meeting C++ 2025

by James McNellis

Watch the video:

Event-driven flows

by Andrzej Krzemieński

From the article:

A canonical example of an event-driven flow is the handling of signals in C. Signals will be risen at unpredictable points in time, so rather than actively checking for them, we define a callback and associate it with the indicated signal:

signal(SIGINT, on_interrupt);

 

After having performed this association, we move on to doing other things. It is the implementation (system, or parts of the program we do not write) that will make sure to invoke the callback when the signal is risen (if at all). We can illustrate it with a diagram:

Converting Between Unicode UTF-16 and UTF-8 in Windows C++ Code

by Giovanni Dicanio

From the article:

A detailed discussion on how to convert C++ strings between Unicode UTF-16 and UTF-8 in C++ code using Windows APIs like WideCharToMultiByte, and STL strings and string views.