Although C++ is one of the most widespread programming languages,[1] many prominent software engineers criticize C++ (the language, and its compilers) arguing that it is overly complex[2] and fundamentally flawed.[3] Among the critics have been: Robert Pike,[4] Joshua Bloch, Linus Torvalds,[5] Donald Knuth, Richard Stallman, and Ken Thompson. C++ has been widely adopted and implemented as a systems language through most of its existence. It has been used to build many pieces of very important software (such types of software include, but are not limited to: operating systems, runtime systems, programming language interpreters, parsers, lexers, compilers, etc...).
The natural interface between source files in C and C++ are header files. Each time a header file is modified, all source files that include the header file should recompile their code. Header files are slow because they are textual and context-dependent as a consequence of the preprocessor.[6] C only has limited amounts of information in header files, the most important being struct declarations and function prototypes. C++ stores its classes in header files and they not only expose their public variables and public functions (like C with its structs and function prototypes) but also their private functions. This forces unnecessary recompilation of all source files which include the header file each time these private functions are edited. This problem is magnified where the classes are written as templates, forcing all of their code into the slow header files, which is the case with much of the C++ standard library. Large C++ projects can therefore be relatively slow to compile.[7] The problem is largely solved by precompiled headers in modern compilers or using the module system that was added in C++20; future C++ standards are planning to expose the functionality of the standard library using modules.[8]
C++ [[Input/output (C++)|<iostream>]], unlike C [[C file input/output|<stdio.h>]], relies on a global format state. This fits very poorly together with exceptions, when a function must interrupt the control flow, after an error but before resetting the global format state. One fix for this is to use resource acquisition is initialization (RAII), which is implemented in the Boost[9] libraries and part of the C++ Standard Library.
<iostream> uses static constructors which causes overhead if included, even if the library is not used.[10] Another source of bad performance is the misuse of std::endl instead of \n when doing output, as it also calls .flush. C++ <iostream> is by default synchronized with <stdio.h> which can cause performance problems in command-line i/o intensive applications. Shutting it off can improve performance but forces giving up some ordering guarantees.
Here follows an example where an exception interrupts the function before std::cout can be restored from hexadecimal to decimal. The error number in the catch statement will be written out in hexadecimal which probably is not what one wants:
int main It is even acknowledged by some members of the C++ standards body[11] that <iostream> is an aging interface that eventually needs to be replaced.
C++20 added std::format that eliminated the global formatting state and addressed other issues in iostreams.[12] For example, the catch clause can now be written as
The philosophy of the Standard Template Library (STL) embedded in the C++ Standard Library is to use generic algorithms in the form of templates using iterators. Early compilers optimized small objects such as iterators poorly, which Alexander Stepanov characterized as the "abstraction penalty", although modern compilers optimize away such small abstractions well.[13] The interface using pairs of iterators to denote ranges of elements has also been criticized.[14] [15] The C++20 standard library's introduction of ranges should solve this problem.[16]
One big problem is that iterators often deal with heap allocated data in the C++ containers and become invalid if the data is independently moved by the containers. Functions that change the size of the container often invalidate all iterators pointing to it, creating dangerous cases of undefined behavior.[17] [18] Here is an example where the iterators in the for loop get invalidated because of the std::string container changing its size on the heap:
int main
The C++11 uniform initialization syntax and std::initializer_list share the same syntax which are triggered differently depending on the internal workings of the classes. If there is a std::initializer_list constructor then this is called. Otherwise the normal constructors are called with the uniform initialization syntax. This can be confusing for beginners and experts alike.[19] [10]
int main
There have been concerns that the zero-overhead principle[20] is not compatible with exceptions.[10] Most modern implementations have a zero performance overhead when exceptions are enabled but not used, but do have an overhead during exception handling and in binary size due to the need to unroll tables. Many compilers support disabling exceptions from the language to save the binary overhead. Exceptions have also been criticized for being unsafe for state-handling. This safety issue has led to the invention of the RAII idiom, which has proven useful beyond making C++ exceptions safe.
C++ string literals, like those of C, do not consider the character encoding of the text within them: they are merely a sequence of bytes, and the C++ string class follows the same principle. Although source code can (since C++11) request an encoding for a literal, the compiler does not attempt to validate that the chosen encoding of the source literal is "correct" for the bytes being put into it, and the runtime does not enforce character encoding. Programmers who are used to other languages such as Java, Python or C# which try to enforce character encodings often consider this to be a defect of the language.
The example program below illustrates the phenomenon.
// note that this code is no longer valid in C++20int main
Despite the presence of the C++11 'u8' prefix, meaning "Unicode UTF-8 string literal", the output of this program actually depends on the source file's text encoding (or the compiler's settings - most compilers can be told to convert source files to a specific encoding before compiling them). When the source file is encoded using UTF-8, and the output is run on a terminal that's configured to treat its input as UTF-8, the following output is obtained:
byte-count of automatically-chosen, [Vår gård på Öland!] = 22 byte-count of ASCII-only [Var gard pa Oland!] = 18 byte-count of explicit ISO-8859-1 bytes [Vr grd p land!] = 18 byte-count of explicit UTF-8 bytes [Vår gård på Öland!] = 22The output terminal has stripped the invalid UTF-8 bytes from display in the ISO-8859 example string. Passing the program's output through a Hex dump utility will reveal that they are still present in the program output, and it is the terminal application that removed them.
However, when the same source file is instead saved in ISO-8859-1 and re-compiled, the output of the program on the same terminal becomes:
byte-count of automatically-chosen, [Vr grd p land!] = 18 byte-count of ASCII-only [Var gard pa Oland!] = 18 byte-count of explicit ISO-8859-1 bytes [Vr grd p land!] = 18 byte-count of explicit UTF-8 bytes [Vår gård på Öland!] = 22One proposed solution is to make the source encoding reliable across all compilers.