October 25, Pavia, Italy
November 6-8, Berlin, Germany
November 3-8, Kona, HI, USA
By niekb | Sep 27, 2025 02:00 PM | Tags: None
Passing a string temporary into a string_view can make the latter dangling
Safely passing std::strings and std::string_view
by Niek J Bouman
From the article:
Many of you will agree that C++ is a language that comes with sharp edges. One example is `std::string_view`; introduced as a type to prevent unnecessary std::string-copies, but it introduces a new footgun, namely when passing a temporary string into it:
By niekb | Sep 27, 2025 01:58 PM | Tags: None
Sometimes some object A needs to interact with another object B, e.g., A calls one of B’s methods. In a language like C++, it is left to the programmer to assure that B outlives A; if B happens to be already destructed, this would be a use-after-free bug. Managing object lifetimes can be tricky, especially with asynchronous code.
A safe pointer in C++ that protects against use after free and updates when the pointee is moved
by Niek J. Bouman
From the article:
We propose a design for a safe pointer to an object of type T that is weak in that it does not have ownership semantics, and gets notified in case the pointee is either destructed or moved.
We will pay a price at runtime for these extra guarantees in terms of a small heap-allocated state, a double pointer indirection when accessing the pointee (comparable to a virtual function call), and a check against nullptr.
The main idea of our design is to internally use a
std::shared_ptr<T*>to share ownership of a (heap-allocated) pointer T*. The ownership is shared by the pointee and allsafe_ptr<T>instances. The pointee type T must derive from the base classsafe_ptr_factory(templated on T, using the Curiously Recurring Template Pattern) with a destructor that automatically notifies the shared state about destruction by setting T* tonullptr, and with a move constructor and move assignment operator that update T* to the new this pointer (which we must properly cast withstatic_cast<T*>). The double indirection thus comes from having to dereference theshared_ptrto obtain an ordinary pointer T*, after which you must dereference once more to access the pointee. You might recognize an instance of Gang-of-Four’s observer pattern in our design.
By Giovanni Dicanio | Sep 27, 2025 01:53 PM | Tags: None
Some reflections on a harsh critic by Linus Torvalds on a RISC-V Linux kernel contribution.
Linus Torvalds and the Supposedly “Garbage Code”
by Giovanni Dicanio
From the article:
So, the correct explicit code is not something as simple as “(a << 16) + b”.
[...] As you can see, the type casts, the parentheses, the potential bit-masking, do require attention. But once you get the code right, you can safely and conveniently reuse it every time you need!
By daminetreg | Sep 27, 2025 01:49 PM | Tags: None
CppCon 2025 was packed with exciting talks, deep dives, and great conversations.
CppCon 2025 Trip Report
by tipi.build by EngFlow
About the report
tipi.build by EngFlow attended both as a developer team and as a CppCon sponsor. Discover in our trip report the highlights from the sessions we attended and the talks we gave, How monday’s afternoon break started with ice cream + key takeaways and resources if you’d like to dive deeper.
By Blog Staff | Sep 25, 2025 03:19 PM | Tags: None
Last week, we discussed why we should sometimes use remove_cvref_t on our template parameters before applying concepts to them. We also saw that the solution is not super readable because we lose access to the terse, shorthand syntax.
C++26: Concept and variable-template template-parameters
by Sandor Dargo
From the article:
C++ already allows passing templates as template parameters, but only if they are class templates. A common reason for doing this is to allow higher-level abstractions. For instance, you may want to pass in a container template like
std::vector, without specifying the type it contains.Jason Turner explains this well in C++ Weekly - Ep 368 - The Power of template-template Parameters: A Basic Guide, but here’s his example for quick reference:
template<template <typename Contained, typename Alloc = std::allocator<Contained>> typename ResultType> auto get_data() { ResultType<double> result; // ... return result; } int main() { auto data = get_data<std::vector>(); }
By Meeting C++ | Sep 25, 2025 07:29 AM | Tags: meetingcpp community
Meeting C++ is offering online and onsite student and support tickets for this years conference!
Highlighting the student and support tickets for Meeting C++ 2025
by Jens Weller
From the article:
I'd like to point towards the programs for those that can't afford to pay for a ticket for Meeting C++ 2025: the programs for the student and support tickets.
And let me start with thanking those that enable these programs through their ticket buying: the attendees and sponsors of Meeting C++ 2025! With the schedule published, I'd like to highlight the student and support tickets for Meeting C++ 2025. For a few years now Meeting C++ has hosted programs to give students, underrepresented folks and those who can't afford a ticket access to the conference.
By Blog Staff | Sep 23, 2025 03:16 PM | Tags: None
Let’s talk about templates, constraints, and concepts. We’ll start with a quick reminder of why concepts are essential when working with templates. Then we’ll dive into the challenge posed by reference-qualified types and finish with a practical solution.
Use concepts with std::remove_cvref_t
by Sandor Dargo
From the article:
By now, it’s well known that using unconstrained templates is discouraged. Even the C++ Core Guidelines strongly recommend against it.
T.47 only advises avoiding highly visible unconstrained templates with common names due to the risks of argument-dependent lookup going wrong. T.10 goes further, recommending that we specify concepts for every template argument to improve both simplicity and readability.
The same idea appears in I.9, which suggests documenting template parameters using concepts.
It’s hard to argue with these guidelines. Concepts make code more readable — just by looking at a function, class, or variable template, the reader can immediately tell what kinds of types are accepted.
If you want to learn more about concepts, check out my concepts-related articles or my book on concepts.
But what makes a good concept? That’s a more complex topic — and one we can’t fully cover in a single article.
By Blog Staff | Sep 19, 2025 03:14 PM | Tags: None
Compile time code can be very efficient. Andrew Drakeford demonstrates how to write efficient chains of matrix multiplication.
Simple Compile-Time Dynamic Programming in Modern C++
by Andrew Drakeford
From the article:
Modern C++ enables us to solve mathematical optimisation problems at compile time. With the expanded constexpr capabilities [Fertig21, Turner18, Turner19, Wu24], we can now write clear and efficient optimisation logic that runs during compilation. Fixed-size containers such as
std::arrayfit naturally into these routines. Even standard algorithms, such asstd::sortandstd::lower_bound, are now constexpr, enabling more straightforward code and more powerful compile-time computations. Additionally, compile-time optimisation generates constant results, which enables the compiler to create even more efficient code. We will use the matrix chain multiplication problem as our worked example.Matrix chain multiplication
Matrix chain multiplication is a classic dynamic programming problem [Corman22, Das19, Mount]. It aims to determine the most efficient method for multiplying a sequence of matrices. Since matrix multiplication is associative, the order of grouping does not affect the result. However, the number of scalar multiplications involved can vary depending on the grouping.
Consider the three matrices A₁ (10×100), A₂ (100×5), and A₃ (5×50), multiplied in a chain, A₁ × A₂ × A₃.
There are two ways to multiply them:
- Grouping as (A₁ × A₂) × A₃ first computes a 10×5 matrix, then multiplies that with A₃. This results in 5,000 operations for the first multiplication, and another 2,500 for the second – a total of 7,500 scalar multiplications.
- Grouping as A₁ × (A₂ × A₃) first multiplies A₂ and A₃, then A₁. This results in 25,000 operations for the first step and 50,000 for the second – a total of 75,000, which is clearly worse.
By Blog Staff | Sep 17, 2025 03:09 PM | Tags: None
In today's post, I like to talk about C++26 and one of the probably most impactful features that have been added to the working draft. While C++26 is still some months away from official completion, since the WG21 summer meeting in June we all now know what will be in C++26.
C++26 reflection at compile-time
by Andreas Fertig
From the article:
While the new standard will have plenty of great improvements the one that will most likely change a lot is reflection at compile-time! In Sofia we voted seven reflection papers into C++26:
- P1306R5 Expansion statements
- P2996R13 Reflection for C++26
- P3096R12: Function parameter reflection in reflection for C++26
- P3293R3: Splicing a base class subobject
- P3394R4: Annotations for reflection
- P3491R3: define_static_
- P3560R2: Error handling in reflection
The papers above should give you enough to read for your vacation. I'll leave that theoretical study up to you for now.
Let's talk practical
The main question is, what can you do with that new feature? Well, I'm not the first one who published their ideas.
By Blog Staff | Sep 15, 2025 03:06 PM | Tags: None
Previously, we discussed how to write our own formatter and finished with a relatively simple solution for printing a struct called ProgrammingLanguage. Today, we’ll take it to the next level.
Format your own type (Part 2)
by Sandor Dargo
From the article:
Add more options for semantic versioning
Let’s dream big. Instead of only handling major and minor versions (like Python 3.12), let’s aim to fully support semantic versioning.
Semantic versioning (SemVer) is a versioning scheme that conveys meaning about the underlying changes in a release. It typically consists of three parts: MAJOR.MINOR.PATCH.
We should be able to print all these correctly:
ProgrammingLanguage cpp{"C++", 20}; ProgrammingLanguage python312{"Python", 3, 12}; ProgrammingLanguage python31211{"Python", 3, 12, 11}; std::cout << std::format("{:%n%v} is fun", cpp) << '\n'; // C++20 is fun std::cout << std::format("{:%n %v} is fun", python312) << '\n'; // Python 3.12 is fun std::cout << std::format("{:%n %v} is fun", python31211) << '\n'; // Python 3.12.11 is fun
