Your attention is invited to the second part of an e-book on undefined behavior. This is not a textbook, as it's intended for those who are already familiar with C++ programming. It's a kind of C++ programmer's guide to undefined behavior and to its most secret and exotic corners. The book was written by Dmitry Sviridkin and edited by Andrey Karpov.

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

by Dmitry Sviridkin

From the article:

The compiler can be guided by the following logic: If the h value is positive—regardless of the c character—the h*27752 + c value will be positive: the c value is small, and there is no overflow. At the first iteration, h is positive, we sum up positive numbers. There are no overflows in a correct program, so at each iteration, the value will be positive. The result will be positive; we no need any check.

In recent discussions around the use of std::move in C++, questions have arisen regarding its potential overuse and the compiler's treatment of its return values. Addressing concerns raised by developers like Jonathan Duncan, this article delves into the nuances of std::move, examining whether its current implementation aligns with compiler optimizations and proposing potential enhancements for more efficient code generation.

More on harmful overuse of std::move

by Raymond Chen

From the article:

Some time ago, I wrote about harmful overuse of std::move. Jonathan Duncan asked,

Is there some side-effect or other reason I can’t see return std::move(name); case isn’t possible to elide? Or is this just a case of the standards missing an opportunity and compilers being bound to obey the standards?

In the statement return std::move(name);, what the compiler sees is return f(...); where f(...) is some mysterious function call that returns an rvalue. For all it knows, you could have written return object.optional_name().value();, which is also a mysterious function call that returns an rvalue. There is nothing in the expression std::move(name) that says, “Trust me, this rvalue that I return is an rvalue of a local variable from this very function!”

Now, you might say, “Sure, the compiler doesn’t know that, but what if we made it know that?” Make the function std::move a magic function, one of the special cases where the core language is in cahoots with the standard library.

This sort of in-cahoots-ness is not unheard of. For example, the compiler has special understanding of std::launder, so that it won’t value-propagate memory values across it, and the compiler has special understanding of memory barriers, so that it won’t optimize loads and stores across them.

Registration is now open for CppCon 2024! The conference starts on September 15 and will be held in person in Aurora, CO. To whet your appetite for this year’s conference, we’re posting videos of some of the top-rated talks from last year's conference. Here’s another CppCon talk video we hope you will enjoy – and why not register today for CppCon 2024!

Linkers, Loaders and Shared Libraries in Windows, Linux, and C++

by Ofek Shilon

Summary of the talk:

This talk would give a crash-intro to linkers, loaders and the layout of program binaries, and explore just enough internals to understand some observable differences in C++ builds between Linux and Windows.

We will discuss the GOT, the PLT, symbol visibility, interposition, lazy binding and more. There will be a lot of details, but also a lot of 'why's and opinions.

We will also touch/rant on what the C++ standard has to say on adjacent matters. There's a good chance you've heard before "shared libraries are outside the scope of the standard", but it doesn't mean what you think it does.

Registration is now open for CppCon 2024! The conference starts on September 15 and will be held in person in Aurora, CO. To whet your appetite for this year’s conference, we’re posting videos of some of the top-rated talks from last year's conference. Here’s another CppCon talk video we hope you will enjoy – and why not register today for CppCon 2024!

Plenary: Libraries - A First Step Toward Standard C++ Dependency Management

by Bret Brown & Bill Hoffman

Summary of the talk:

Prebuilt libraries have existed for decades… they even predate C++! After all these years, techniques to use prebuilt libraries are still ad hoc and difficult to maintain. A root cause of this variety of techniques is the variety of things that are C++ libraries: header-only libraries, statically-linked archives, dynamically-linked binaries, and so on. The consuming projects need to build against these libraries in consistent ways or risk unproductive workflows – and potentially, even catastrophic failure in production environments. This lack of convergence creates enormous interoperability problems across broad portions of the worldwide programming ecosystem, not just the C++ parts of it.

This talk will explore the complexities of defining what is a “C++ library.” It will then present the joint work of Kitware, Bloomberg, and others toward a preliminary design for creating initial standards for dependency management in C++ – metadata files to describe prebuilt libraries. A roadmap for maturing the design will also be shared, including proposing a standard definition for C++ libraries, building on previous proposals such as P1313: Package Specification (https://wg21.link/P1313).

This talk is intended for anyone who produces, maintains, or consumes C++ libraries. Special knowledge of C++ tooling, build systems, or package managers is not required.

Sean Baxter demonstrates memory safe C++ using his Circle compiler

Safe C++
Sean Baxter

From the talk:

Does a subset of a superset of C++ exists that achieves similar safety guarantees to rust, is useful and expressive enough, and is compatible with today's C++? If so, is anyone mad enough to do it? There is an answer to that