You should use QPainterPath they said...

By Meeting C++ | Oct 8, 2025 10:21 AM | Tags: qt meetingcpp community

A blog entry about this years t-shirt at Meeting C++ 2025 and exploring QPainterPath for it.

You should use QPainterPath they said...

by Jens Weller

From the article:

This post is about what I learned while playing around with QPainterPath for this years t-shirt at Meeting C++ 2025 sponsored by Hudson River Trading.

One of the issues from last years t-shirt was when using drawText from QPainter, one does not really *draw* text in an svg exported. Instead you'll get the text and the font kinda embedded in an svg. What good is that in a vector graphic? This was a bit of a surprise when I ran into issues with this last year during printing. While this could be solved with the printing company picking a different font, it would have been also solved by using QPainterPath. At least this was the feedback from some of the Qt experts present onsite or online...

 

How to Look up Values in a Map -- Sandor Dargo

By Blog Staff | Oct 1, 2025 12:38 PM | Tags: None

Whether you’re in a coding interview or writing production code, you’ll eventually face the question: What’s the right way to look up values in a std::map or std::unordered_map? For simplicity, we’ll refer to both containers as maps in this post.

How to Look up Values in a Map

by Sandor Dargo

From the article:

Let’s explore the different options — along with their pros and cons.

operator[]

Using operator[] is the old-fashioned way to access elements of a map. It takes a key and returns a reference to the corresponding value. The complexity is log(n) for std::map and average constant time (with worst-case linear) for std::unordered_map.

However, there’s a big caveat.

What if the key is not present in the map?

Unlike a vector — where accessing an invalid index with operator[] leads to undefined behavior — a map will instead insert a new entry with the given key and a default-constructed value. This side effect makes operator[] unsafe for lookups where insertion is not desired.

Safely passing strings and string_views -- Niek J Bouman

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:

A safer C++ pointer class -- Niek J. Bouman

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 all safe_ptr<T> instances. The pointee type T must derive from the base class safe_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* to nullptr, and with a move constructor and move assignment operator that update T* to the new this pointer (which we must properly cast with static_cast<T*>). The double indirection thus comes from having to dereference the shared_ptr to 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.

Linus Torvalds and the Supposedly Garbage Code -- Giovanni Dicanio

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!

CppCon 2025 Trip Report – tipi.build by EngFlow

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.

C++26: Concept and variable-template template-parameters -- Sandor Dargo

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>();
}

Use concepts with std::remove_cvref_t -- Sandor Dargo

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.

Simple Compile-Time Dynamic Programming in Modern C++ -- Andrew Drakeford

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::array fit naturally into these routines. Even standard algorithms, such as std::sort and std::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:

1. 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.
2. 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.

C++26 reflection at compile-time -- Andreas Fertig

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.