In the last post of this series we started exploring how to erase an element from the middle of a vector.

Qt and Trivial Relocation (Part 3)

by Giuseppe D'Angelo

From the article:

The reference semantics backstab

Let’s start by analyzing erase()‘s behavior once more.

Do you remember our claim that the specific strategy used does not really matter; that is, that they are all equivalent? Well, not so fast! It is actually quite imprecise to say that they are all equivalent.

They may be, as long as we deal with types which have value semantics. If we instead use a type that has reference semantics, the choices are absolutely not equivalent, and will yield different outcomes. This is because the semantics of assignment for (certain) reference types are write-through: they assign through the reference (instead of rebinding the reference).

Since we are implementing erasure in terms of assignments (or swaps, which boil down to assignments), this means that the precise sequence of operations done by erase will be visible due to its side-effects; and it also means that changing the strategy will produce different outcomes!

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!

Lightning Talk: Writing a Better std::move

by Jonathan Müller

Summary of the talk:

std::move allows the creation of const rvalue references, which is almost always wrong. It also allows moving out of lvalue references, which can be dangerous since you don't have real ownership over them and a caller might not expect the object to disappear. Let's fix those problems using macros, reflection, and more macros.

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.