Understand Internals of std::expected

by Bartlomiej Filipek

In short, std::expected should contain two data members: the actual expected value and the unexpected error object. So, in theory, we could use a simple structure:

template <class _Ty, class _Err> 
struct expected {  
     /*... lots of code ... */  
     _Ty _Value;  
     _Err _Unexpected; 
}; 

However, there are better solutions than this. Here are some obvious issues for our “struct” approach.

• The size of the object is the sum of the Value type and the Error type (plus padding if needed).
• Two data members are “active” and initialized, which might not be possible - for example, what if the Value type has no default constructor? The Standard requires that std::expected" holds either a value of type Tor an error of typeE` within its storage.
• We’d have to guarantee that _Ty cannot be a reference type or an array type; it must be a Destructible Type.
• Similarly for the _Err type we have to guarantee that it’s also Destructible, and must be a valid template argument for std::unexpected (so not an array, non-object type, nor cv-qualified type).
• Plus, we’d have to write a lot of code that creates an API for the type

C++ programmer's guide to undefined behavior: part 1 of 11

by Dmitry Sviridkin

Many modern programming languages, especially newer ones, forbid implicit type conversions. So, in Rust, Haskell, or Kotlin, we can't just use float and int in the same arithmetic expression without explicitly stating in the code to convert one to the other. Python isn't as strict but still keeps strings, characters, and numbers from mixing. C++ doesn't forbid implicit conversion, which leads to a lot of erroneous code. Moreover, such code can contain both defined (but unexpected) and undefined behavior.

Delivering Safe C++

by Bjarne Stroustrup

Type safety was one of the key initial C++ design ideals. We have evolved C++ to the point where we can write C++ with no violations of the type system, no resource leaks, no memory corruption, no garbage collector, no limitation of expressiveness or performance degradation compared to well-written modern C++.

We face three major challenges: To define what “safe” means in the context of various C++ uses, to guarantee such safety where guarantees are needed, and to get developers to write such verified safe code.

I outline an approach based on safety profiles to address these challenges, describe an approach to eliminate dangling pointers, and suggest how to eliminate all dangling pointers and all range errors. My aim for key applications is verified type-and-resource-safe C++. An emphasis is on minimizing costly run-time checks through the use of abstractions. I see the current emphasis on safety as an opportunity to complete one aspect of C++’s fundamental aims in real-world code.

Speaking about C++

Organized by Jens Weller

This event will focus on the process of creating technical talks for the C++ community. Various speakers will share their views on how to submit, prepare and give talks to the C++ community in the form of lightning talks and a panel.

Qt and Trivial Relocation (Part 1)

by Giuseppe D'Angelo

The container classes introduced in Qt 4 (Tulip, for the aficionados) had an interesting optimization: the ability to turn certain operations on the contained objects into byte-level manipulations.

Example: vector reallocation

Consider the reallocation of a QVector<T>: when the vector is full and we want to insert a new value (of type T), the vector has to allocate a bigger block of memory.

Error on verge of extinction, or why I put if (x = 42) in Red List of C & C++ bugs

by Andrey Karpov

Because of this bug, developers invented the Yoda notation: a programming style where the constant is placed on the left side of the comparison operator. This style was meant to prevent a typo. If a programmer writes = instead of ==, the code won't compile.

Plenary: Cooperative C++ Evolution - Toward a Typescript for C++

by Herb Sutter

C++23 is done. But C++ is not! In this talk I’ll give my personal perspectives on:

• C++’s ongoing and very active evolution;
• The latest progress updates on my cppfront experimental compiler, and what I’ve learned about modern ISO C++20 and C++23 in the experiment (https://github.com/hsutter/cppfront);
• Why compatibility (and what kind, and how much) is essential; and
• Why we should aim to keep bringing C++ forward successfully by cooperating and being part of C++’s ongoing true evolution via WG 21, even though that’s more work than pursuing a new fresh-but-competing evolutionary path.

Lightning Talk: ClangFormat Is Not It

by Anastasia Kazakova

Sometimes things are not what we think of them. But we keep using them based on our perception. ClangFormat is a widely used tool by the C++ community. Join me to explore the typical delusions around it.