Perfect Match

The quiet times are over for C++. A full 13 years passed between the C++98 and C++11 standards, but since then, new standards have appeared every three years, with C++14, C++17, and preliminary work on C++20. The C++ standardization committee already shows signs of enthusiasm for the next cycle.

With so many versions of C++ out in the world (see the "Blessings of Diversity" box), a developer could easily wonder, how do the compiler makers keep up with it all? This article looks at support for C++ standards in three popular compiler alternatives:

• GCC: The GNU Compiler Collection (GCC) [1] is the quintessential free software compiler. Originally created by Richard Stallman in 1987 as the compiler for the GNU project, GCC is now supported by a large community of developers and is found on almost all Linux distributions.
• Clang: This popular free compiler collection [2] uses the LLVM compiler as a back end. Clang is actually the front-end component. Clang/LLVM is designed for a high degree of compatibility with GCC. The Clang project enjoys the support of several major vendors, including Apple, Google, Microsoft, Intel, and AMD, possibly because they find Clang's permissive free software license easier to integrate with commercial projects than the GPL3 license attached to GCC.
• MSVC: This compiler is for Microsoft's Visual C++ (MSVC) environment [3]. In the past, Linux support in a major Microsoft development tool would have been unthinkable, but today, versions of MSVC run on Linux, and extensions are available for developing Linux applications on MSVC.

In this article, you'll also learn about some online compiler front ends that let you test your code for different compilers and standards, which often leads to valuable insights, optimizations, and troubleshooting tips.

Compilers and Standards

An estimated 95 percent of all C++ developers rely on the GCC, Clang, or MSVC compilers. The timeline in Figure 1 shows the existing C++ standards, with the exception of C++03, which was only released as a bug fix for C++98 in 2003. This article focuses on C++11, C++14, and C++17. I will avoid looking back (C++98) or into the future (C++20).

Figure 1: The C++ standard evolves and extends with each new version.

Table 1 shows which compiler versions support the C++11, C++14, and C++17 standards.

The table refers to support for the C++ core language. Sometimes that support is only partially complete. MSVC 19.1, for instance, only partially supports C++17, and this support requires the third update. Tables 2 and 3 show all the details of C++17 support [5].

If you are not satisfied with the information provided on the big three compilers, or if you are interested in the C++ compilers that other Unix platforms have to offer, you can also find more detailed information on the current C++ standards at the C++ Reference website [5].

Support for the C++ standard library (STL) varies a little. There is currently no implementation of the parallel STL in C++17. You have to do some tinkering work to find a solution: The High Performance Parallex (HPX) library [6], for instance, is a framework for parallel and distributed applications that already implements the parallel STL.

Important Compiler Flags

In order to use the correct C++ standard, you need to specify it for GCC or Clang. Both support the same flags. Thus the

g++ -std=c++11 dataRace.cpp

call compiles the dataRace.cpp file source code according to the C++11 standard. You can also specify C++14 or C++17. This step is not necessary for newer versions of GCC and Clang, but not all compiler-to-C++ standard combinations can cope without this specification, and it will not do any harm to specify. MSVC does not require you to specify the C++ standard.

There are some other interesting compiler flags for developers. For example, -O3 (for GCC and Clang) and /Ox (for MSVC), for example, generate a maximum optimized program, and -Wall (for GCC and Clang) or /Wall (for MSVC) set the maximum warning level.

Sanitize

Sanitizer [7], a tool that checks whether the code correctly uses addresses, threads, and memory, has been available since GCC 4.8 and Clang 3.2. MSVC users will have to try their luck with a Windows port [8].

A small example will help illustrate the power of the Thread Sanitizer [9]. The program in Listing 1 contains code that can clearly lead to a race condition, since several threads access the globalVal variable at the same time. More precisely, both threads try to change the variable at the same time.

Compile Thread Sanitizer into GCC and Clang by using the -fsanitize=thread flag:

g++ -std=c++11 dataRace.cpp  -fsanitize=thread -pthread -g -o dataRace

then run the program compiled here with GCC; it will generate output that identifies the potential race condition (Figure 2). At the end, the output also shows the sequence of the built-in data race.

Figure 2: The compiler detects a race condition thanks to Thread Sanitizer.