Articles & Books

C++ exceptions and memory allocation failure -- Wu Yongwei

C++ exceptions are habitually disabled in many software projects. A related issue is that these projects also encourage the use of new (nothrow) for fear of exceptions. Is it good practice or bad practice? Also, how likely are we to really encounter out-of-memory errors? I will investigate on this topic and discuss strategies to deal with memory issues.

C++ Exceptions and Memory Allocation Failure

By Wu Yongwei

From the article:

In fact, every time we initialize or modify a string, vector, or map, we may be allocating memory on the heap. If we think that new will end in an exception (and therefore choose to use new (nothrow)), exceptions may also occur when using these mechanisms. In a program that has disabled exceptions, the result will inevitably be a program crash.

Ignoring abnormal scenarios like allocating more memory than the physical memory size at a time (which would likely be a logic error in the program), can a reasonable program still experience memory allocation failures?

C++23: static operator() and static operator[] -- Sandor Dargo

sandordargo.jpgIn this article, we are going to review two new features of C++23. Now the language allows the call operator (operator()) and the subscription operator (operator[]) to be static.

C++23: static operator() and static operator[]

By Sandor Dargo

From the article:

static operator()

As we saw earlier in our big C++ algorithms tutorial, function objects are extensively used in the standard library to customise the behaviour of several functions. With the introduction of ranges in C++20 (and of earlier non-standard libraries), the usage of function objects became even more widespread.

Many function objects are extremely simple. Let’s take an implementation of isEven.

auto isEven = [](int i) {return i % 2 == 0;};

2023-08 Mailing Available

The 2023-08 mailing of new standards papers is now available.

 

WG21 Number Title Author Document Date Mailing Date Previous Version Subgroup
N4956 Concurrency TS2 PDTS Michael Wong 2023-08-15 2023-08   All of WG21
N4958 Working Draft, Programming Languages -- C++ Thomas Köppe 2023-08-14 2023-08   All of WG21
N4959 Editors' Report, Programming Languages -- C++ Thomas Köppe 2023-08-14 2023-08   All of WG21
N4960 Business Plan and Convener's Report: ISO/IEC JTC1/SC22/WG21 (C++) Herb Sutter 2023-08-09 2023-08   All of WG21
P0124R7 Linux-Kernel Memory Model Paul E. McKenney 2023-08-22 2023-08 P0124R6 SG1 Concurrency and Parallelism,SG5 Transactional Memory,SG14 Low Latency
P0124R8 Linux-Kernel Memory Model Paul E. McKenney 2023-08-22 2023-08 P0124R7 SG1 Concurrency and Parallelism,SG5 Transactional Memory,SG14 Low Latency
P0963R1 Structured binding declaration as a condition Zhihao Yuan 2023-08-14 2023-08 P0963R0 EWG Evolution
P1068R8 Vector API for random number generation Ilya Burylov 2023-08-08 2023-08 P1068R7 LEWG Library Evolution
P1967R11 #embed - a simple, scannable preprocessor-based resource acquisition method JeanHeyd Meneide 2023-08-21 2023-08 P1967R10 CWG Core
P2407R5 Freestanding Library: Partial Classes Ben Craig 2023-07-26 2023-08 P2407R4 LWG Library
P2521R5 Contract support -- Record of SG21 consensus Andrzej Krzemieński 2023-08-15 2023-08 P2521R4 SG21 Contracts
P2728R6 Unicode in the Library, Part 1: UTF Transcoding Zach Laine 2023-08-14 2023-08 P2728R5 SG16 Unicode,LEWG Library Evolution
P2746R3 Deprecate and Replace Fenv Rounding Modes Hans Boehm 2023-08-14 2023-08 P2746R2 SG6 Numerics,LEWG Library Evolution
P2795R3 Erroneous behaviour for uninitialized reads Thomas Köppe 2023-07-28 2023-08 P2795R2 SG12 Undefined and Unspecified Behavior,SG23 Safety and Security,EWG Evolution,CWG Core
P2821R4 span.at() Jarrad J. Waterloo 2023-07-26 2023-08 P2821R3 SG23 Safety and Security,LEWG Library Evolution
P2833R1 Freestanding Library: inout expected span Ben Craig 2023-08-19 2023-08 P2833R0 LEWG Library Evolution
P2845R2 Formatting of std::filesystem::path Victor Zverovich 2023-07-23 2023-08 P2845R1 SG16 Unicode,LEWG Library Evolution
P2863R1 Review Annex D for C++26 Alisdair Meredith 2023-08-16 2023-08 P2863R0 EWG Evolution,LEWG Library Evolution
P2864R1 Remove Deprecated Arithmetic Conversion on Enumerations From C++26 Alisdair Meredith 2023-08-16 2023-08 P2864R0 SG22 Compatability,EWG Evolution
P2865R2 Remove Deprecated Array Comparisons from C++26 Alisdair Meredith 2023-08-16 2023-08 P2865R1 SG22 Compatability,EWG Evolution
P2868R1 Remove Deprecated `std::allocator` Typedef From C++26 Alisdair Meredith 2023-08-15 2023-08 P2868R0 LEWG Library Evolution
P2869R1 Remove Deprecated `shared_ptr` Atomic Access APIs From C++26 Alisdair Meredith 2023-08-16 2023-08 P2869R0 LEWG Library Evolution
P2870R1 Remove `basic_string::reserve()` From C++26 Alisdair Meredith 2023-08-16 2023-08 P2870R0 LEWG Library Evolution
P2871R1 Remove Deprecated Unicode Conversion Facets From C++26 Alisdair Meredith 2023-08-08 2023-08 P2871R0 LEWG Library Evolution
P2875R1 Undeprecate `polymorphic_allocator::destroy` For C++26 Alisdair Meredith 2023-08-15 2023-08 P2875R0 LEWG Library Evolution
P2878R5 Reference checking Jarrad J. Waterloo 2023-08-10 2023-08 P2878R4 SG23 Safety and Security
P2885R1 Requirements for a Contracts syntax Timur Doumler 2023-08-15 2023-08 P2885R0 SG21 Contracts,EWG Evolution
P2890R0 Contracts on lambdas Timur Doumler 2023-08-17 2023-08   SG21 Contracts
P2894R0 Constant evaluation of Contracts Timur Doumler 2023-08-22 2023-08   SG21 Contracts
P2896R0 Outstanding design questions for the Contracts MVP Timur Doumler 2023-08-22 2023-08   SG21 Contracts
P2905R2 Runtime format strings Victor Zverovich 2023-07-23 2023-08 P2905R1 LWG Library
P2909R0 Dude, where's my char? Victor Zverovich 2023-08-13 2023-08   SG16 Unicode,LEWG Library Evolution
P2933R0 std::simd overloads for <bit> header Daniel Towner 2023-08-01 2023-08   SG1 Concurrency and Parallelism,LEWG Library Evolution
P2935R0 An Attribute-Like Syntax for Contracts Joshua Berne 2023-08-15 2023-08   SG21 Contracts
P2944R1 Comparisons for reference_wrapper Barry Revzin 2023-08-17 2023-08 P2944R0 LEWG Library Evolution
P2951R2 Shadowing is good for safety Jarrad J. Waterloo 2023-08-10 2023-08 P2951R1 SG23 Safety and Security
P2952R0 auto& operator=(X&&) = default Arthur O'Dwyer 2023-08-10 2023-08   EWGI SG17: EWG Incubator,EWG Evolution
P2953R0 Forbid defaulting operator=(X&&) && Arthur O'Dwyer 2023-08-10 2023-08   EWGI SG17: EWG Incubator,EWG Evolution
P2954R0 Contracts and virtual functions for the Contracts MVP Ville Voutilainen 2023-08-03 2023-08   SG21 Contracts
P2955R0 Safer Range Access Jarrad J. Waterloo 2023-08-10 2023-08   SG23 Safety and Security
P2956R0 Add saturating library support to std::simd Daniel Towner 2023-08-01 2023-08   SG1 Concurrency and Parallelism,LEWG Library Evolution
P2957R0 Contracts and coroutines Andrzej Krzemieński 2023-08-15 2023-08   SG21 Contracts
P2958R0 typeof and typeof_unqual JeanHeyd Meneide 2023-08-21 2023-08   EWG Evolution
P2960R0 Concurrency TS Editor's report for N4956 Michael Wong 2023-08-16 2023-08   All of WG21

C++23: Syntactic Sugar with Deducing This -- Rainer Grimm

syntacticsugar-grimm.pngThe Curiously Recurring Template Pattern (CRTP) is a heavily used idiom in C++. It is similarly resistant to understanding as the classic design pattern visitor I presented in my last post: “C++23: Deducing This“.  Thanks to deducing this, we can remove the C and R from the abbreviation.

C++23: Syntactic Sugar with Deducing This

By Rainer Grimm

From the article:

CRTP

The acronym CRTP stands for the C++ idiom Curiously Recurring Template Pattern and denotes a technique in C++ in which a class Derived is derived from a class template Base. The critical point is that Base has Derived as a template argument.

template <typename T>
class Base{
    ...
};

class Derived : public Base<Derived>{
    ...
};
CRTP is typically used to implement static polymorphism. Unlike dynamic polymorphism, static polymorphism happens at compile time and does not require an expensive run-time pointer indirection.

Introduction to Programming with C++ For Engineers, Book Review -- Bartlomiej Filipek

introprogramming-book.pngLots of practical examples, general programming, software development techniques, OOP, parallel algorithms, plus C++ to combine it all into working applications. This is a short introduction to the book “Introduction to Programming with C++” by Prof. Boguslaw Cyganek, an excellent book for students who start their journey with system coding.

Introduction to Programming with C++ For Engineers, Book Review

By Bartlomiej Filipek

From the review:

“I have been highly impressed by Introduction to Programming with C++ for Engineers and can’t recommend it enough. With its content designed keeping in mind the author’s own students, the book assumes no prior programming experience, making it an excellent choice for anyone who wishes to learn C++ as their first programming language. […]
The book extends its reach beyond just the programming language, shedding light on aspects such as microprocessor operations, software development processes, UML, and more. Furthermore, the appendices cover essential tools like CMake and Git, making this book a comprehensive guide for anyone delving into C++ programming. The detailed content, careful attention to detail, and clarity in explaining concepts have garnered much praise for the book. This makes it an invaluable resource for those aspiring to learn and understand modern C++ programming."

Let's Enumerate the UB -- Shafik Yaghmour

ShafikYaghmour.jpgSome time ago I started working on P1705 Enumerating Core Undefined Behavior, I have collected a large set of undefined behavior (UB) during that time. There is going to be a lot of work involved in getting the annex into shape and editing it into the standard. While this work is ongoing, I will take some time to write blog posts to explore the set of undefined behaviors.

Let's Enumerate the UB

By Shafik Yaghmour

From the article:

In these posts I will cover: why we have each undefined behavior, some consequences of running afoul of each UB and tools we can use to catch UB. My plan is to enumerate them in the order they appear in the standard.

IFNDR (What is that?)

Before we go on, let’s talk about a term we find in the standard, ill-formed no diagnostic required; also known as IFNDR. This is like undefined behavior in that the standard places no requirements on a program that contains IFNDR constructs, see [intro.compliance.general]p2.2 which says (emphasis mine):

If a program contains a violation of a rule for which no diagnostic is required, this document places no requirement on implementations with respect to that program.

compared to the defintion of undefined behavior which says:

behavior for which this document imposes no requirements

The main difference is that IFNDR is a static property of your code (it is a propety of the program).

C++23: Deducing This -- Rainer Grimm

grimm-deducingthis.pngAnyone who thinks a small C++ standard follows a significant C++ standard is wrong. C++23 provides powerful extensions to C++20. These extensions include the core language, particularly the standard library. Today, I present a small but very impactful feature of the core language: deducing this.

C++23: Deducing This

By Rainer Grimm

From the article:

Deducing this, sometimes also called explicit object parameter, allows it to make the implicit this pointer of a member function explicit. Like Python, the explicit object parameter must be the first function parameter and is called in C++, by convention, Self and self.
struct Test {

    void implicitParameter();               // implicit this pointer
    void explictParameter(this Self& self); // explicit this pointer
};
Deducing this enables new programming techniques in C++23: deduplication of function overloading based on the object’s lvalue/rvalue value category and constness. Additionally, you can reference a lambda and invoke it recursively. Furthermore, deducing this simplifies the implementation of CRTP

How To Address 7 Major C++ Pain Points with CLion -- Anastasia Kazakiova

Anastasia-200x200.jpgIn the 2023 Annual C++ Developer Survey conducted by the C++ Foundation, the community identified a number of major pain points when working with C++.

How To Address 7 Major C++ Pain Points with CLion

By Anastasia Kazakiova

From the article:

As we’ll discuss in this article, CLion can help C++ developers with most of these in various ways:

  • Managing third-party libraries
  • Improving build times
  • Setting up a CI-pipeline
  • Managing a CMake project
  • Checking code for thread, memory and type safety issues on-the-fly
  • Setting up a development environment from scratch
  • Modernize your code

RFC - fat pointer class, evolution of YOMM2 -- Reddit Q&A

reddit.pngQuestion from reddit poster: I am preparing to release a new feature, a fat pointer class (virtual_ptr), that makes method dispatch even more efficient. Dispatching a method with one virtual argument via a virtual_ptr takes only three instructions and two independent memory reads. As an interesting side-effect, it is now possible to use YOMM2 with non polymorphic classes hierarchies.

RFC - fat pointer class, evolution of YOMM2

From the discussion:

I am preparing to release a new feature, a fat pointer class (virtual_ptr), that makes method dispatch even more efficient. Dispatching a method with one virtual argument via a virtual_ptr takes only three instructions and two independent memory reads. As an interesting side-effect, it is now possible to use YOMM2 with non polymorphic classes hierarchies.

Once I increase the semantic minor version number, I will mostly be stuck with the API. So, if you are interested and in the mood, please review the documentation.

Beyond this, I have been mulling a major version bump. There are a few stuff that are deprecated, and I would like to get rid of them.

Also, I wonder if it would be a good time to switch to C++20. The internals would be a lot simpler and cleaner if I could use concepts.

I have a few major developments on the radar:I have a few major developments on the radar:

  • dispatch on std::any and std::variant
  • "fat" versions of std::any and std::variant (in the manner of virtual_ptr)
  • going headers only
  • related to the former: tunable runtime
  • quasi static initialization of method tables

I wonder if it would be better to wait until these items are completed before switching to C++20 and putting the C++17 code in bugfix only mode.

Finite State Machine with std::variant - Vending Machine -- Bartlomiej Filipek

In my last article, we discussed Finite State Machines based on std::variant and some cool C++17 techniques. Today I want to go further and show you an example of a Vending Machine implementation.

Finite State Machine with std::variant - Vending Machine

By Bartlomiej Filipek

From the article:

Here’s a basic diagram that illustrates how the machine is going to work:

vending_states.png

Following the model from the last article, each state and the event will be a separate small structure. Later we can “pack” them into std::variant.