The C++ fundamentals your seniors think they know -- Mateusz Pusz

By Mateusz Pusz | Oct 16, 2026 12:39 PM | Tags: None

Pointer provenance, the One Definition Rule, name lookup, and move semantics are not beginner topics. They are the load-bearing rules that decide whether code which compiles is actually correct. This is the opening article of a series on the ones experienced C++ developers most often get wrong, each post opening on a failure that reached production.

The C++ fundamentals your seniors think they know

by Mateusz Pusz

From the article:

Here is a five-second test. Ask an experienced C++ developer what new Connection{host} does, given a constructor that can throw. Almost everyone says “it calls operator new.” Almost no one names the new-expression: the language construct that first calls operator new to obtain raw storage and then constructs the object in it, two separate steps that the one keyword hides.

That gap is not trivia. It is why people write an operator new that tries to construct the object, cannot say who does the construction if operator new does not, cannot say who frees the storage when the constructor throws, and get caught out by placement new. The rule was there the whole time. Nobody ever pointed at it.

Published so far:

• Your reinterpret_cast is undefined behavior (you just got lucky)
• Your pointer still remembers the old object

On Contracts and Safety -- Lucian Radu Teodorescu

By Blog Staff | Oct 14, 2026 12:35 PM | Tags: None

Composing safe functions may not be safe. Lucian Radu Teodorescu explores how C++26 contracts help uncover problems.

On Contracts and Safety

by Lucian Radu Teodorescu

From the article:

If two operations are safe, is their composition safe too? At first glance, the answer ought to be yes. But a small expression such as f(g(10)) can appear to contradict that intuition: both functions may be safe under their own contracts, while the nested call still violates memory safety. The missing piece is the caller. Safety does not compose merely because expressions are nested; it composes when obligations and guarantees line up at each boundary.

Building on the previous article [Teodorescu26], this article looks at how contracts help us build safe programs. Contracts give us a structured way to describe obligations and guarantees, both at software boundaries and inside implementations. In that context, we briefly describe C++26 contracts.

We then look more closely at a common source of confusion around the composability of safety. We also consider enforced safe operations as a practical way to build safe programs with respect to selected safety properties. Finally, we look at documentation contracts as a complementary way to express contracts that do not belong in code. Both forms help build safety into applications.

Contracts

‘Design by Contract’ is the discipline of making the obligations and guarantees of software components explicit [Meyer91]. A routine may impose preconditions on its callers, promise postconditions on return, and preserve invariants associated with the object or module it belongs to. The main point is not just that these predicates may be checked, but that they make the boundary between client and implementation explicit.

C++26 contracts bring part of this discipline into the language [P2900]. The core idea is that users can add contract assertions to programs, providing machine-checkable statements about expected program behaviour. These contract assertions come in three forms: preconditions, postconditions, and general-purpose assertion statements.

C++26 Reflection: Simplifying JSON Serialization -- Vivek Bhadra

By Blog Staff | Oct 12, 2026 12:30 PM | Tags: None

C++26 reflection opens the door to eliminating much of the repetitive, error-prone code involved in JSON serialization. In this post, we’ll build on the basics of reflection and explore how it can automatically map the members of a user-defined class to JSON, even as the class evolves.

C++26 Reflection: Simplifying JSON Serialization

by Vivek Bhadra

From the article:

In the previous post I have discussed the basic usage of C++26’s latest (still experimental) feature called reflection. In this post we will look into a more concrete problem which many of us have come across called JSON serialization. We often receive the data in the form of an object of a user defined class. And what we need to do is to format it in JSON format which means to associate the data member names in the class definition with their respective values and put them in a JSON structure. First lets have a look at a hypothetical CanDataSource class as below:

Releasing the full program of Meeting C++ 2026

By Meeting C++ | Oct 12, 2026 06:59 AM | Tags: meetingcpp conference community

The full program of Meeting C++ 2026 is now available:

Schedule of Meeting C++ 2026

The full Meeting C++ 2026 program is released

by Jens Weller

From the article:

appy to announce that all slots in the program for Meeting C++ 2026 are now filled!

With that the schedule for this years conference is complete! Most of it has been visible already for months, there are a few minor editions, ... like the keynotes:

    Mateusz Pusz - Why Great C++ Libraries Fail (And How to Fix That)
    Kate Gregory - Brains And Belonging

 

C++26: Reducing undefined behaviour -- Sandor Dargo

By Blog Staff | Oct 9, 2026 12:48 PM | Tags: None

C++26 continues the language’s push toward safer, more predictable code by reducing situations that can lead to undefined behaviour. This article looks at several key changes that turn dangerous runtime surprises into diagnosable errors or well-defined behaviour.

C++26: Reducing undefined behaviour

by Sandor Dargo

From the article:

Nowadays, safety is in the focus of C++. Whether it’s at committee meetings, conference talks, or hallway discussions, the topic keeps coming up. C++26 made some big steps forward in this area, and one recurring theme is the reduction of cases leading to undefined behaviour.

With the words of one of the presented proposals, “undefined behaviour has all but unbounded potential for bad program behaviour, including security leaks, data corruption, deadlocks, and so on”. The simple act of violating a precondition can silently turn a perfectly correct-looking program into one that exhibits any of these.

In today’s article, we look at how and where C++26 addresses this. A couple of these changes we have already covered on this blog, but they are worth reiterating in this context. And there is one important change we haven’t talked about yet. Let’s start with that.

P3144R2: Deleting a Pointer to an Incomplete Type Should be Ill-formed

Before C++26, deleting a pointer to an incomplete type was undefined behaviour. The only exception was when the complete class type happened to have a trivial destructor and no class-specific deallocation function. In all other cases, the compiler simply could not know what to do.

Understanding std::counting_semaphore and std::binary_semaphore from C++20 -- Bartlomiej Filipek

By Blog Staff | Oct 8, 2026 11:11 AM | Tags: None

How fast is C++26’s std::hive? -- Daniel Lemire

By Blog Staff | Oct 6, 2026 11:08 AM | Tags: None

C++26 introduces std::hive, a new container designed to combine stable references and efficient erasure with better memory locality than a linked list. But where does it actually fit performance-wise compared with std::vector and std::list?

How fast is C++26’s std::hive?

by Daniel Lemire

From the article:

C++26 adds a new container to the standard library: std::hive. It is meant to occupy the ground between std::vector and std::list. Like a vector, it keeps its elements in contiguous blocks of memory, so scanning it does not require you to chase a pointer for every element. Like a list, it never moves an element once it has been inserted: your pointers, references and iterators stay valid, and you may erase any element in constant time without disturbing the others.

Internally, a hive is a linked list of blocks. Each block carries a skipfield: a small integer per slot that tells the iterator how many erased slots to jump over.

No standard library ships std::hive yet to my knowledge. Fortunately there is an implementation (plf::hive by Matt Bentley) as a single header file that you can use today.

I use elements of type uint64_t, GCC 16.1 with -O3 -march=native, on an Intel Xeon Gold 6548N (Emerald Rapids), pinned to one core. Numbers are nanoseconds per element, along with the cycles and instructions retired per element.

We start from an empty container and append a million values. The container is then destroyed.

The Prompt-Wait-Evaluate Loop: How AI Kills Flow Without You Noticing -- Sandor Dargo

By Blog Staff | Oct 2, 2026 11:05 AM | Tags: None

AI coding assistants may help us produce more code, but they can also quietly change the way we experience the work itself. The constant prompt-wait-evaluate cycle can disrupt the deep focus that makes programming engaging, turning what looks like productive work into a series of subtle interruptions.

The Prompt-Wait-Evaluate Loop: How AI Kills Flow Without You Noticing

by Sandor Dargo

From the article:

A few months ago, I wrote about finding joy in programming in the age of AI. In the personal discussions I’ve had with fellow developers — both before and after that article — one thing keeps striking me. Most people don’t argue. They just say: yes, that’s exactly how it feels.

But a question kept coming up in those conversations: why does it feel this way? Not in the philosophical sense — I covered that. In the mechanical sense. What is actually happening to our attention when we work with AI coding assistants?

I want to explore that topic more deeply, because I think understanding the mechanism matters. It’s the difference between vaguely sensing that something is off and being able to do something about it.

What flow actually is

In 1990, the psychologist Mihaly Csikszentmihalyi published Flow: The Psychology of Optimal Experience, the book that gave a name to what probably all of us had already experienced. Flow is the state of full absorption where action and awareness merge. You lose track of time. Self-consciousness fades. The work just happens.

Lets explore the stack

By Meeting C++ | Oct 2, 2026 09:25 AM | Tags: meetingcpp community basics

The second post in a new blog series at Meeting C++!

Lets explore the stack

by Jens Weller

From the article:

Part two in the new C++ content, as I've spend some time creating content to be now released in front of Meeting C++ 2026.

Maybe read last weeks post About alignment, struct layout and the cache first.

Maybe its a good idea to continue in an area which a lot of other things build upon: the stack, followed by the heap and visiting RAII. Modern programs usually have other memory areas too, like read only sections or a place where static text is stored. Exploring these is also fun, but gets one into an area ruled by the OS and hardware dependent memory layout. Which may differ between the wide range of C++ usage...