The LLVM compiler project provides a header file called STLExtras.h that extends the capabilities of C++ without any dependency on the rest of LLVM. In this article, we take a quick look at its basic functionality.
Continue reading “Extend C++ capabilities with LLVM STLExtras.h”
The summer 2019 C++ meeting was in Cologne, Germany, 10 years since our last meeting in Germany. As usual, Red Hat sent three of us to the meeting: I attended in the Core language working group (CWG), Jonathan Wakely in Library (LWG), and Thomas Rodgers in SG1 (parallelism and concurrency).
Continue reading Report from July 2019 ISO C++ Meeting (Core Language)
Among the most heavily used string handling functions declared in the standard C <string.h> header are those that copy and concatenate strings. Both sets of functions copy characters from one object to another, and both return their first argument: a pointer to the beginning of the destination object. The choice of the return value is a source of inefficiency that is the subject of this article.
The code examples shown in this article are for illustration only. They should not be viewed as recommended practice and may contain subtle bugs.
Continue reading “Efficient string copying and concatenation in C”
Back in February, I attended the WG21 C++ standards committee meeting in rainy Kona, Hawaii (yes, it rained most of the week). This report is so late that we’re now preparing for the next meeting, which will take place mid-July in Cologne.
As usual, I spent the majority of my time in the Library Working Group (for LWG; for details on the various Working Groups and Study Groups see Standard C++: The Committee). The purpose of the LWG is to formalize the specification of the C++ Standard Library, i.e. the second “half” of the C++ standard (although in terms of page count it’s closer to three quarters than half). With a new C++20 standard on the horizon, and lots of new features that people want added to the standard library, the LWG has been very busy trying to process the backlog of new proposals forwarded by the Library Evolution Working Group (LEWG).
Continue reading “Report from the February 2019 ISO C++ meeting (Library)”
The February 2019 ISO C++ meeting was held in Kailua-Kona, Hawaii. As usual, Red Hat sent three of us to the meeting: I attended in the SG1 (parallelism and concurrency) group, Jonathan Wakely in Library, and Jason Merrill in the Core Working Group (see Jason’s report here). In this report, I’ll cover a few highlights of the meeting, focusing on the papers that were discussed.
Continue reading “Report from February 2019 ISO WG21 C++ Standards Committee Meeting”
Most C compilers allow accessing an array declared extern, which has indeterminate bounds, like this:
extern int external_array[];
int
array_get (long int index)
{
return external_array[index];
}
The definition of external_array could reside in a different translation unit and look like this:
int external_array[3] = { 1, 2, 3 };
The question is what happens if this separate definition is changed to this:
int external_array[4] = { 1, 2, 3, 4 };
Or this:
int external_array[2] = { 1, 2 };
Does either change preserve the binary interface (assuming that there is a mechanism that allows the application to determine the size of the array at run time)?
Curiously, the answer is that on many architectures, increasing the array size breaks binary interface (ABI) compatibility. Decreasing the array size may also cause compatibility problems. We’ll look more closely at ABI compatibility in this article and explain how to avoid problems.
Continue reading “How C array sizes become part of the binary interface of a library”
One of the most important concepts introduced in C++11 was move semantics. Move semantics is a way to avoid expensive deep copy operations and replace them with cheaper move operations. Essentially, you can think of it as turning a deep copy into a shallow copy.
Move semantics came along with several more or less related features, such as rvalue references, xvalues, forwarding references, perfect forwarding, and so on. The standard C++ library gained a function template called std::move, which, despite its name, does not move anything. std::move merely casts its argument to an rvalue reference to allow moving it, but doesn’t guarantee a move operation. For example, we can write a more effective version of swap using std::move:
template<typename T>
void swap(T& a, T& b)
{
T t(std::move (a));
a = std::move (b);
b = std::move (t);
}
This version of swap consists of one move construction and two move assignments and does not involve any deep copies. All is well. However, std::move must be used judiciously; using it blithely may lead to performance degradation, or simply be redundant, affecting readability of the code. Fortunately, the compiler can sometimes help with finding such wrong uses of std::move. In this article, I will introduce two new warnings I’ve implemented for GCC 9 that deal with incorrect usage of std::move.
Continue reading “Understanding when not to std::move in C++”
The February 2019 ISO C++ meeting was held in Kailua-Kona, Hawaii. As usual, Red Hat sent three developers to the meeting: I attended in the Core Language working group, Jonathan Wakely in Library, and Thomas Rodgers in SG1 (parallelism and concurrency). The meeting went smoothly, although there was significant uncertainty at the beginning where we would end up. In the end, Modules and Coroutines were accepted into the C++20 draft, so now we have our work cut out for us nailing down the remaining loose corners. Here ar highlights from the meeting.
Continue reading “Report from the February 2019 ISO C++ meeting (Core Language working group)”
A few bugs have been lurking in the LLVM Bugzilla for a long time, namely #39427 and #35978, which are related to a custom implementation of the is_trivially_copyable data type, and they have a bad impact on the Application Binary Interface (ABI) of LLVM libraries. In this article, I will take a closer look at these issues and describe potential workarounds.
The LLVM compiler infrastructure relies on several Advanced Data Types (ADT) to provide different speed/size trade-offs than the containers from the Standard Template Library (STL). Additionally, this ADT library provides features from future standard versions, but implemented in the C++ version (currently C++11) that LLVM supports as a code base. Finally, these ADTs must be compatible with the compiler requirements of the LLVM code base; basically, GCC version >= 4.8 and Clang version >= 3.1. (If you are interested in LLVM ADTs, Chandler Carruth did a nice talk on the subject at CppCon 2016.)
Continue reading “A look at LLVM Advanced Data Types and trivially copyable types”
I work at Red Hat on GCC, the GNU Compiler Collection, and I spent most of the past year making GCC easier to use. Let’s look at C and C++ improvements that will be in the next major release of GCC, GCC 9.
Continue reading “Usability improvements in GCC 9”