Contracts for C++ Explained in 5 Minutes -- Timur Doumler

By Blog Staff | Apr 3, 2025 12:50 PM | Tags: None

Contract assertions, introduced in proposal P2900 for C++26, provide a robust mechanism for runtime correctness checks, offering more flexibility and power than the traditional assert macro. This blog post will explore how contract assertions work, their various evaluation semantics, and how they can improve code reliability with preconditions, postconditions, and custom violation handlers.

Contracts for C++ Explained in 5 Minutes

by Timur Doumler

From the article:

With P2900, we propose to add contract assertions to the C++ language. This proposal is in the final stages of wording review before being included in the draft Standard for C++26.

It has been suggested by some members of the C++ standard committee that this feature is too large, too complicated, and hard to teach. As it turns out, the opposite is true: contract assertions are actually very simple and can be explained in just five minutes. In this blog post, we will do exactly this!

As the name says, contract assertions are assertions — correctness checks that the programmer can add to their code to detect bugs at runtime. So they’re just like the existing assert macro, except they’re not macros (which fixes a bunch of problems) and they’re way more flexible and powerful!

contract_assert replaces assert

Our replacement for assert is called contract_assert. Unlike assert, contract_assert is a proper keyword, but it works in the same way:

 

auto w = getWidget(); 

contract_assert(w.isValid());  // a contract assertion

processWidget(w);

 

The default behaviour is also the same: the assertion is checked, and if the check fails, the program prints a diagnostic message and terminates.

A Pattern for Obtaining a Single Value While Holding a Lock -- Raymond Chen

By Blog Staff | Apr 1, 2025 12:46 PM | Tags: None

When working with a mutex-protected variable, you often need to read or modify its value while holding the lock, but then operate on the value outside the lock to minimize contention. While the traditional approach involves copying the value within a locked scope, using an immediately-invoked lambda or helper function can streamline this process, enabling efficient copy elision or move semantics to optimize performance.

A Pattern for Obtaining a Single Value While Holding a Lock

by Raymond Chen

From the article:

It is often the case that you have a mutex or other lockable object which protects access to a complex variable, and you want to read the variable’s value (possibly modifying it in the process) while holding the lock, but then operate on the value outside the lock.

The traditional way is to do something like this:

// Assume we have these member variables
std::mutex m_mutex;
Widget m_widget;

// Get a copy of the widget
Widget widget;
{
    auto guard = std::lock_guard(m_mutex);
    widget = m_widget;
}
⟦ use the variable "widget" ⟧

This does suffer from the problem of running the Widget constructor for an object that we’re going to overwrite anyway. The compiler will also have to deal with the possibility that the lock_guard constructor throws an exception, forcing the destruction of a freshly-constructed Widget.

Fun with C++26 reflection - Keyword Arguments -- Che

By Blog Staff | Mar 28, 2025 12:44 PM | Tags: None

In this blog post, we’ll explore implementing order-independent keyword arguments for C++ through use of C++26’s proposed reflection features. I stumbled upon this technique while experimenting with reflection a few days ago and thought it might be worthwhile to share, as it nicely showcases just how powerful the proposed reflection features are.

Fun with C++26 reflection - Keyword Arguments

by Che

From the article:

An example implementation of the technique presented in this blog post can be found on GitHub. It can be used with Bloomberg’s experimental P2996 clang fork. If you enjoy these shenanigans, feel free to leave a star.

Prior art

Named, labeled or keyword arguments have been proposed many times over the years, but as EWG issue 150 notes: all of these attempts have failed. Here is several past proposals on the topic:

• n4172 Named arguments
• p1229 Labelled Parameters
• p0671 Self-explanatory Function Arguments

Since none of these proposals were accepted, we have to be somewhat creative to get similar functionality in C++. Naturally, there are various approaches to this problem. Below is a short overview of what you can already do without reflection.

Designated initializers

Let’s start with the simplest way to achieve keyword argument-like syntax. C++20 introduced designated initializers for aggregate types, which gives us the initialization syntax Point{.x=42, .y=7}.

In a function call’s argument list the type can potentially be deduced, so we could write foo({.x=2, .y=2}). While this requires extra curly braces and .-prefixes for every member name, syntactically this is almost what we want.

A Brief and Incomplete Comparison of Memory Corruption Detection Tools -- Raymond Chen

By Blog Staff | Mar 26, 2025 01:27 PM | Tags: None

Memory diagnostic tools can be divided into runtime detection tools like Address Sanitizer (ASAN), Valgrind, and Application Verifier, and recording tools like rr and Time Travel Debugging (TTD). While runtime tools help catch memory errors as they occur, recording tools allow developers to trace memory modifications over time, making them a powerful combination for debugging complex issues.

A Brief and Incomplete Comparison of Memory Corruption Detection Tools

by Raymond Chen

From the article:

I promised last time to do a comparison of memory diagnostic tools. We have runtime diagnostic tools Address Sanitizer (ASAN), Valgrind, and Application Verifier (AppVerifier, avrf), and we have recording tools rr, and Time Travel Debugging (TTD)

First, the runtime tools:

ASAN detects a lot more types of memory errors, but it requires that you recompile everything. This can be limiting if you suspect that the problem is coming from a component you cannot recompile (say because you aren’t set up to recompile it, or because you don’t have the source code). Valgrind and AppVerifier have the advantage that you can turn them on for a process without requiring a recompilation. That means that you can ask a customer to turn it on at their site, without having to deliver a custom build to them. This is even more important on Windows because you have no chance of giving them an ASAN-enabled version of, say, kernel32.dll.

Reminder: When a C++ Object Fails to Construct, the Destructor Does Not Run -- Raymond Chen

By Blog Staff | Mar 24, 2025 01:24 PM | Tags: None

In C++, if an object’s constructor fails (due to an exception), destructors are run for the object’s member variables and base classes, but not for the object itself. The principle at play is that you cannot destruct something that was never constructed in the first place.

Reminder: When a C++ Object Fails to Construct, the Destructor Does Not Run

by Raymond Chen

From the article:

Consider this pull request:

com_timeout_t(DWORD timeoutInMilliseconds)
    : m_threadId(GetCurrentThreadId())
{
    m_cancelEnablementResult = CoEnableCallCancellation(nullptr);
    err_policy::HResult(m_cancelEnablementResult);
    if (SUCCEEDED(m_cancelEnablementResult))
    {
        m_timer.reset(CreateThreadpoolTimer(
            &com_timeout_t::timer_callback, this, nullptr));
        err_policy::LastErrorIfFalse(
            static_cast<bool>(m_timer));
        if (m_timer)
        {
            FILETIME ft = filetime::get_system_time();
            ft = filetime::add(ft, filetime::
                    convert_msec_to_100ns(timeoutInMilliseconds));
            SetThreadpoolTimer(m_timer.get(), &ft,
                    timeoutInMilliseconds, 0);
        }
    }
}

~com_timeout_t()
{
    m_timer.reset();

    if (SUCCEEDED(m_cancelEnablementResult))
    {
        CoDisableCallCancellation(nullptr);
    }
}

⟦ member variables: ⟧

HRESULT m_cancelEnablementResult{};
DWORD m_threadId{};
bool m_timedOut{};
wil::unique_threadpool_timer_nocancel m_timer;

The idea is that the constructor first calls Co­Enable­Call­Cancellation and reports the failure via err_policy::HResult().

Bjarne Stroustrup's Vision for 21st Century C++ -- Darryl K. Taft & David Cassel

By Blog Staff | Mar 22, 2025 01:37 PM | Tags: None

Bjarne Stroustrup, the creator of C++, has outlined his vision for the language’s future in his article "21st Century C++," emphasizing the need for safer and more modern coding practices without abandoning its powerful legacy. His approach advocates for incremental improvements, such as guideline-enforcing profiles and enhanced type safety, ensuring C++ remains relevant in an era of heightened security and performance demands.

Bjarne Stroustrup's Vision for 21st Century C++: Balancing Legacy, Safety, and Innovation

by Darryl K. Taft & David Cassel

From the article:

Bjarne Stroustrup, the mind behind the venerable C++ programming language, has once again entered the fray to shape the language’s future, publishing a weighty, 6,300-word piece titled "21st Century C++" in Communications of the ACM. Central to his argument is the idea that while C++ itself cannot drastically change due to its extensive legacy, the practices surrounding it can and must adapt. His manifesto outlines a path forward, advocating for tools like guideline-enforcing profiles to detect and mitigate coding errors, alongside a deliberate, type-safe evolution of the language. Stroustrup's call to action is as much about preserving the language's relevance in an era of heightened attention to memory safety as it is about addressing criticism aimed at C++’s historical complexities.

"21st Century C++" and the Pursuit of Safety Without Sacrificing Power

C++ is a linguistic titan. It powers systems that range from high-frequency trading platforms to embedded systems in spacecraft, and yet its intricate, low-level control has often been a double-edged sword. For Stroustrup, the path forward lies in preserving this power while ensuring safer usage—a delicate dance that avoids alienating the vast community reliant on its compatibility with decades-old code. In "21st Century C++," Stroustrup suggests that the way forward lies in shifting the culture and tools surrounding the language, rather than the language itself.

One of the most critical elements of his vision is the concept of "guideline-enforcing profiles."

The Case of the Crash When Trying to Erase an Element from a std::set -- Raymond Chen

By Blog Staff | Mar 21, 2025 01:17 PM | Tags: None

Today, we’ll look at a crash that occurred when trying to erase an element from a std::set.

The Case of the Crash When Trying to Erase an Element from a std::set

by Raymond Chen

From the article:

rax=000001f565bc046e rbx=000001f589b20340 rcx=000001f565bc046e
rdx=000000e6658feca8 rsi=000001f589b20690 rdi=000001f589b203c0
rip=00007ffdd4726bc4 rsp=000000e6658fec30 rbp=0000388a1713ab55
 r8=000001f589b895d0  r9=000001f589b895d0 r10=000001f589000140
r11=0000000000000000 r12=0000000000000001 r13=000000007ffe0385
r14=0000000000000000 r15=000001f589b8f900

LitWare!std::_Tree<std::_Tset_traits<WidgetWatcher *,
        std::less<WidgetWatcher *>,
        std::allocator<WidgetWatcher *>,0> >::_Eqrange+0x14
    [inlined in LitWare!std::_Tree<std::_Tset_traits<
        WidgetWatcher *,std::less<WidgetWatcher *>,
        std::allocator<WidgetWatcher *>,0> >::erase+0x18]:
00007ffd`d4726bc4 cmp     byte ptr [rax+19h],r11b ds:000001f5`65bc0487=??

The stack trace has some information about how we got here.

LitWare!std::_Tree<std::_Tset_traits<Widget *,
        std::less<Widget *>,
        std::allocator<Widget *>,0> >::_Eqrange+0x14
LitWare!std::_Tree<std::_Tset_traits<Widget *,
        std::less<Widget *>,
        std::allocator<Widget *>,0> >::erase+0x18
LitWare!Widget::~Widget+0xc8
LitWare!Widget::`scalar deleting destructor'+0x14
LitWare!DestroyWidget+0x15
Fabrikam!Doodad::~Doodad+0x75
Fabrikam!Doodad::`scalar deleting destructor'+0x14
Fabrikam!Doodad::Release+0x40
Contoso!Gadget::~Gadget+0x66
ucrtbase!<lambda_⟦...⟧>::operator()+0xa5
ucrtbase!__crt_seh_guarded_call<int>::operator()<⟦...⟧>+0x3b
ucrtbase!__acrt_lock_and_call+0x1c
ucrtbase!_execute_onexit_table+0x3d
Contoso!dllmain_crt_process_detach+0x45
Contoso!dllmain_dispatch+0xe6
ntdll!LdrpCallInitRoutine+0xb0
ntdll!LdrShutdownProcess+0x260
ntdll!RtlExitUserProcess+0x114
kernel32!FatalExit+0xb
ucrtbased!exit_or_terminate_process+0x3a
ucrtbased!common_exit+0x85
ucrtbased!exit+0x16

C++ for Embedded Systems: constexpr and consteval -- Andreas Fertig

By Blog Staff | Mar 18, 2025 01:12 PM | Tags: None

In today's post, I'll learn how modern C++ can influence the code you write for your embedded system. You will see code using up to C++23. The example I show you below circles around at least two questions I got various times from customers: What is consteval good for? What is that user-defined literal operator, and why should I care?

C++ for Embedded Systems: constexpr and consteval

by Andreas Fertig

From the article:

Chapter One: What is a MAC address?

I teach a lot of classes to customers who are developing embedded systems. That makes sense. I worked for a long time in that domain, and I enjoyed it so much.

One recurring topic is networking. While nowadays we have various different network types and technologies, let's use the Internet Protocol (IP) today. The base of network communication is your Network Interface Card (NIC). Each NIC has a unique Medium Control Address (MAC) assigned. The MAC address is the base layer for everything on top, like TCP/IP.

A MAC address consists of exactly six bytes. One way to represent a MAC address in code is this:

A Simplified Overview of Ways to Add or Update Elements in a std::map -- Raymond Chen

By Blog Staff | Mar 14, 2025 01:05 PM | Tags: None

The std::map subscript operator ([]) is a convenient but sometimes dangerous feature, as it can create unintended default-constructed entries. By understanding the behavior of various map insertion and lookup methods—such as insert, emplace, try_emplace, and insert_or_assign—developers can write more efficient and predictable code while avoiding unnecessary key-value creations and duplicate lookups.

A Simplified Overview of Ways to Add or Update Elements in a std::map

by Raymond Chen

From the article:

Some time ago, I mentioned how the std::map subscript operator is a dangerous convenience. In that article, I linked to an overview of the insertion emplacement methods, but I’m going to recapture the essential points in a table.¹

In the table below, the discussion of “consumed” or “not consumed” refers to the case that v is an rvalue reference like std::move(something).

We can reorganize the table by effect.

Exercise: Why are the bottom left two boxes blank?

C++26: pack indexing -- Sandor Dargo

By Blog Staff | Mar 12, 2025 01:00 PM | Tags: None

C++26 introduces pack indexing as a core language feature, making it significantly easier to extract specific elements from parameter packs using a familiar subscript syntax. This improvement, proposed by Corentin Jabot and Pablo Halpern, eliminates the need for cumbersome workarounds like recursive templates or boolean expression tricks, providing a more intuitive and readable approach.

C++26: pack indexing

by Sandor Dargo

From the article:

C++11 introduced parameter packs to provide a safer way to pass an undefined number of parameters to functions instead of relying on variadic functions.

While packs are a useful feature, and since C++17 it’s so easy to use them in fold expressions, extracting a specific element of a pack is somewhat cumbersome.

You either have to rely on some standard functions not made for the purpose or use “awkward boolean expression crafting or recursive templates”. None of them is unbearable, but it might be error-prone or simply expensive regarding compile-time performance. Nevertheless, they are not the most readable solutions.

C++26 brings us pack indexing as a core language feature thanks to the proposal of Corentin Jabot and Pablo Halpern, P2662R3.

Before discussing some interesting points, first, let’s look at an example: