We have to admit that reading this chapter will not be a straightforward process, but we will try to make it as easy as possible. Our minds will wander between platforms, compilers, and different dialects of the C++ language. However, at some point, we must draw the line and conclude that we should be able to transform all this theoretical transfer of information into the practicalities of life and produce some C++ code out of it. So, we kindly ask that at this stage of the book, you have access to the almighty internet, and the go-to place for experimental C++: Matt Godbolt’s site:

https://gcc.godbolt.org/

That place should keep you covered since almost all the compilers we will discuss in this chapter are to be found there.

There is nothing else required for now. That’s because at this stage, we have not produced enough valuable code to be able to put anything meaningful into the GitHub repository of the book, and the code that we have...

When Richard Appiah Akoto posted a few images of himself drawing the user interface of Microsoft Word on a blackboard at his school in Ghana, he instantly became a social media phenomenon overnight1. His school was poor and they had no working computers, just a standard blackboard from the turn of the century, but this did not stop him from performing his duties as a teacher. In a very creative manner, he did his best to convey life-altering knowledge to his pupils, hoping that one day, it would be useful for them in their quest for a better life. The rest is history, but the real question is: was this the standard way of teaching Microsoft Word?

Let’s not diverge too much from our initial objective. We want to find out about the standard compliance of C++ programs. For...

That’s enough staring backward for now. Let’s look, for a moment, in a different direction and consider a compiler that once was the king of C++, but with time, its shine faded. OpenWatcom is an open source integrated development environment and suite of compilers for C and C++ (and Fortran too, but that language is not in focus in this book), originally developed by Watcom International Corporation and released as open source by Sybase in 2003.

It supports multiple operating systems, including DOS, Windows, OS/2, and also Linux, and is the de-facto compiler for programmers who have an interest in creating fun, free-time projects for retro platforms.

Not necessarily for the money, but instead for that joyful feeling of sweet nostalgia shivering through one’s spine when they are in front of an 80x25 screen. Maybe that’s the reason most senior programmers today use a grid of VI editors running in a terminal tiled...

Two of the three major compilers today are developed and maintained in an open-source manner. This means that, in theory, anyone can contribute and provide useful new features to their compiler of choice. However, in practice, it means that there is a tiny core of professional programmers who have the necessary knowledge and dedication, and also the backing of a large corporation benefiting from the development of the aforementioned compiler working on it.

In no particular order, GCC and Clang (and MSVC, which we discussed in the previous section) are the most standard-compliant compilers as of 2024. This standard compliance, however, does not mean that these compilers don’t come with their own perks that a developer once thought would be a great idea to incorporate.

Let’s take, for example, the computed goto feature of GCC (and Clang too, of course; those two tend to go hand in hand). We all have learned in school that goto is just plain...

The long list of standard-non-compliant-but-still-working-and-useful features does not end with the preceding examples. However, if we had only focused our attention on those, we could still have filled several books with them. Sadly, for the moment, we have only dedicated one chapter to this topic, so let’s move our attention to somewhat more exotic features.

Qt has been the de-facto cross-platform programming framework for GUI applications (but not only) for quite some time. Throughout its fateful history, while exchanging owners several times since its inception in 1994, the Qt framework has evolved significantly, with each release giving a new set of features to the C++ (but not only) programming community. However, one feature has remained more or less the same: the signal/slot implementation and the Meta Object Compiler (MOC). The pillar of the framework, the MOC makes it possible to connect events from components (i.e., signals) to receivers...

Up until now, we have observed cases where the standard compliance was at the developers’ own discretion. They had the option to choose their platform, use the extensions provided by their favorite compiler, or go for pure standard C++. However, out there in the wild wide world, there are certain circumstances wherein we cannot fully comply with the standard due to some restrictions imposed upon us by the environment that disallows the usage of certain features found in the C++ standard.

Not considering obscene scenarios, when we must maintain decades-old legacy code written in the golden age of C++ (i.e., before the standardization committee took over and ruined all the fun by demanding standard compliance, in order to avert the uncontrollable spread of C++ dialects as happened with BASIC), there are situations outside of our control that make the usage of the full C++ standard features impossible. For example, there might be certain...

The last scenario that we will explore concerning the standard compliance of the code you write relates to the most fundamental item in the C++ ecosystem: the compiler itself.

You see, compilers are also programs, consisting of millions and millions of lines of code. There are several contributors spread out on the globe working on them, adding new features, fixing bugs, making them more standard compliant, releasing the latest versions, and generally making sure that your compiler just works.

These compilers also have a development timeline. The implementation of features does not happen overnight, and there simply might be situations wherein, at a certain point in time, some compiler does not support some feature of the standard because there was not enough manpower to implement it.

There is a very handy document available at the source of all C++ knowledge8, which details the support of various C++ standard features and which compilers have support...

As this chapter has demonstrated, writing standard C++ ensures code portability, compatibility, and maintainability across different platforms and compilers. We learned that by adhering to the ISO/IEC C++ standard, we can create code that behaves predictably and is less prone to bugs and platform-specific issues. Standard-compliant C++ code also benefits from generic compiler optimizations and future language enhancements, while ensuring long-term relevance and performance, as we learned in this chapter.

On the other hand, using C++ compiler-specific extensions can provide performance optimizations specific to a platform and compiler, access to advanced features that are not yet standardized, and integration with vendor-specific tools. However, the extension may introduce portability issues, dependencies on specific compiler versions, as well as divergence from standard C++ practices, which can impact code maintenance and interoperability across different platforms and compilers...