2025

You should use QPainterPath they said...

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

 

Final call for sponsors for Meeting C++ 2025

With Meeting C++ 2025 coming closer, we're doing a last round of onboarding for sponsors

Final call for sponsors for Meeting C++ 2025

by Jens Weller

From the article:

With Meeting C++ 2025 just being 5 weeks away, I share a call for sponsors with you.

Maybe your employer is interested in being present as a sponsor at this years Meeting C++ conference? Have you thought about the possibilty that you could have your employer sponsor Meeting C++ 2025?

As an organization Meeting C++ gets its funding through sponsorship and ticket sales for the conference mostly.

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

SANDOR_DARGO_ROUND.JPGWhether 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

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

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

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

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

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

Highlighting the student and support tickets for Meeting C++ 2025

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.

 

Use concepts with std::remove_cvref_t -- Sandor Dargo

SANDOR_DARGO_ROUND.JPGLet’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.