Criticism of C++

Although C++ is one of the most widespread programming languages, C++ (the language and its compilers) has received various criticisms. Some arguments include that it is overly complex and fundamentally flawed. Among the critics have been: Rob Pike, Joshua Bloch, Linus Torvalds, 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 important software such as operating systems, runtime systems, programming language interpreters, parsers, lexers, compilers, etc.

Complexity

One of the most often criticized points of C++ is its perceived complexity as a language, with the criticism that a large number of non-orthogonal features in practice necessitates restricting code to a subset of C++, thus forfeiting the readability benefits of common style and idioms. Joshua Bloch, a software engineer who developed several Java platform features, called C++ "pushed well beyond its complexity threshold", and criticised the language for its overabundance of features leading to different users using different subsets of the language, which he believed would decrease programmer and code portability. This sentiment was echoed by Donald Knuth, who stated that it was impossible for him to write portable code unless he avoided "all exotic features", while also calling the language "too baroque" for his taste. Knuth in 1993 mentioned of Edsger Dijkstra that to think of programming in C++ "would make him physically ill".

Ken Thompson, who was a colleague of Bjarne Stroustrup at Bell Labs, critiqued the language for its design by committee and aggregation of ideas that he deemed mutually exclusive, calling the language "just the union of everything that came along".

Undefined behavior

Main article: Undefined behavior

Undefined behavior refers to behavior at runtime that the C++ standard does not guarantee how the program will continue upon the violation of such a rule, rendering the entire program meaningless. Undefined behavior exists to allow compilers to make optimizations on the assumption that certain behaviors never happen. Undefined behavior is criticized for security vulnerability and being hard to avoid. Examples of undefined behavior include dereferencing a null pointer, freeing memory more than once, use of a pointer or memory after deallocation, out-of-bounds accessing of an array index, as well as various uses of const_cast and reinterpret_cast.

In C++26, with the introduction of erroneous behavior and safety improvements, some cases previously considered undefined behavior are now detected as compile errors. These include reading uninitialized variables, returning a reference to a temporary variable, and deleting a pointer to an incomplete type.

Here are some code examples that cause undefined behavior:

import std;

double obtainSomeNumber() noexcept {
    return 3.14;
}

const double& mischievousFunction() {
    // undefined behavior prior to C++26 (returning a reference to a temporary object)
    return obtainSomeNumber();
}

int main() {
    float number = 2.718f;
    float* addr = &number;
    addr = nullptr;
    
    float val = *addr; // undefined behavior (dereferencing a nullptr)
    
    char* addr2 = reinterpret_cast<char*>(0xB80000);
    char segfault = *addr2; // undefined behavior (segmentation fault, trying to access random addresses)

    int dummy;
    // undefined behavior prior to C++26 (reading an uninitialized variable)
    std::println("{}", dummy);
}

Slow compile times

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 must be preprocessed and then parsed, as well as the headers that it includes, transitively, leading to redundant work compiling headers that may even be shared between translation units. 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.

The problem is largely solved by precompiled headers in modern compilers or using the module system that was added in C++20; C++23 exposes the functionality of standard library through the standard modules.

Rob Pike, the creator of the Go programming language, complained about compilation times in C++ during his work at Google.

Global format state of <iostream>

C++ <iostream>, unlike C <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 libraries and part of the C++ Standard Library.

<iostream> uses static constructors which may cause overhead if included, even if the library is not used. Another source of bad performance is the use 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:

import std;

using std::bad_alloc;
using std::vector;

int main() {
    try {
        std::cout << std::hex << 0xFFFFFFFF << '\n';
        vector<int> v(0xFFFFFFFFFFFFFFFFull); // std::bad_alloc will be thrown here
        std::cout << std::dec; // Never reached; issue could be solved using scope guarding
    } catch (const bad_alloc& e) {
        std::cout << "Error number: " << 10 << '\n';  // Not in decimal
    }
}

It is even acknowledged by some members of the C++ standards body 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. For example, the catch clause can now be written as std::cout << std::format("Error number: {}\n", 10);, which is not affected by the stream state. The design of std::format permits more performant implementations, comparable or even faster (because of locale independence) to that of printf.

C++23 added std::print and std::println which are both formatted, now no longer relying on direct calls to std::cout and std::cerr and not relying on repetitive string concatenations, simplifying the example further:

std::println("Error number: {}", 10);

Iterators

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. The interface using pairs of iterators to denote ranges of elements has also been criticized. The C++20 standard library's introduction of the std::ranges library solves this problem.

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. 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:

import std;

using std::string;

int main() {
    string text = "One\nTwo\nThree\nFour\n";
    // Let's add an '!' where we find newlines
    for (auto it = text.begin(); it != text.end(); ++it) {
        if (*it == '\n') {
            // it =
            text.insert(it, '!') + 1;
            // Without updating the iterator this program has
            // undefined behavior and will likely crash
        }
    }
    std::print("{}", text);
}

Uniform initialization syntax

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. Uniform initialization also prevents narrowing conversions like precision loss during double to int conversion (for example, initializations like int x{5.5}; are not allowed). Furthermore, the uniform initialization syntax eliminates the problem called most vexing parse, which is about the interpretation of the compiler about declaration is a function or an object. This can be confusing for beginners and experts alike.

using std::vector;

// Two initializations of int (other than int x = 10;)
int a{10};
int b(10);

// Declared with initializer list
// Produces a vector containing {10, 0}
vector<int> v1{10, 0};

// Declared with constructor with (size_t, int)
// Produces a vector of 10 0's
vector<int> v2(10uz, 0);

Exceptions

There have been various criticisms made against C++ exceptions, some of which include that they violate the zero-overhead principle, that they increase binary size, that they prevent compiler optimizations, or that exception unwinding is "effectively" single-threaded. 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 unwind the call stack. 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.

Encoding of string literals in source-code

Template:OR section

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:Template:Outdated inline

#include <iostream>
#include <string>

int main() {
    // all strings are declared with the UTF-8 prefix

    // file encoding determines the encoding of å and Ö
    std::string auto_enc = u8"Vår gård på Öland!";
    // this text is well-formed in both ISO-8859-1 and UTF-8
    std::string ascii = u8"Var gard pa Oland!";
    // explicitly use the ISO-8859-1 byte-values for å and Ö
    // this is invalid UTF-8
    std::string iso8859_1 = u8"V\xE5r g\xE5rd p\xE5 \xD6land!";
    // explicitly use the UTF-8 byte sequences for å and Ö
    // this will display incorrectly in ISO-8859-1
    std::string utf8 = u8"V\xC3\xA5r g\xC3\xA5rd p\xC3\xA5 \xC3\x96land!";

    std::cout << "byte-count of automatically-chosen, [" << auto_enc
              << "] = " << auto_enc.length() << '\n';
    std::cout << "byte-count of ASCII-only [" << ascii << "] = " << ascii.length()
              << '\n';
    std::cout << "byte-count of explicit ISO-8859-1 bytes [" << iso8859_1
              << "] = " << iso8859_1.length() << '\n';
    std::cout << "byte-count of explicit UTF-8 bytes [" << utf8
              << "] = " << utf8.length() << '\n';
}

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!] = 22

The 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!] = 22

One proposed solution is to make the source encoding reliable across all compilers.

Ecosystem and standard library

• C++ lacks a central ecosystem, similar to that of Rust, leading to challenges with interoperability, and has also been suggested to hinder further development. CMake, often seen as the "de-facto standard" build tool, has often been criticised for its verbosity and complexity, compared to the simpler Cargo build system and package manager for Rust. Proposals for ecosystem standardization have been made to potentially rectify such a problem.
• C++ does not separate the standard library into finer namespaces. While this has gradually changed, such as with the introduction of namespaces std::chrono & std::this_thread (C++11), std::filesystem (C++17), std::ranges & std::numbers (C++20), and std::meta (C++26), traditionally the C++ standard library placed all of its symbols in namespace std without further division. This is unlike some other languages, such as Rust or Java, whose standard libraries have namespaces such as std::collections and std::io for Rust, and java.util and java.io for Java.
• C++ naming conventions are not unified. The C++ Standard Library and Boost libraries (following the so-called "Core Guidelines" which are maintained by Bjarne Stroustrup and Herb Sutter but not officially ratified by the ISO C++ standards committee) use snake_case, however camelCase and PascalCase (similar to Java) remains equally prevalent in newer or more modern code bases (such as those of Google, Clang/LLVM or Meta).

See also

• Most vexing parse
• Function overloading § Complications
• Operator overloading § Criticisms
• Exception handling § Criticism
• Argument-dependent name lookup § Criticism
• Object slicing

References

Works cited

• Stroustrup, Bjarne (1994). The Design and Evolution of C++. Addison-Wesley. ISBN 0-201-54330-3. Search this book on

Further reading

• Peter Seibel (2009). Coders at Work: Reflections on the Craft of Programming. Apress. ISBN 978-1430219484. Search this book on

External links

• C++ FQA Lite by Yossi Kreinin
• "C++ The COBOL of the 90s" chapter 10 in The Unix Haters Group Book
• C++ in Coders at Work Excerpts from the book Coders at Work, by Peter Seibel
• DConf 2014: The Last Thing D Needs A video of a talk by Scott Meyers
• A Critique of C++ and Programming and Language Trends of the 1990s - 3rd Edition by Ian Joyner - 1996

This article "Criticism of C++" is from Wikipedia. The list of its authors can be seen in its historical and/or the page Edithistory:Criticism of C++. Articles copied from Draft Namespace on Wikipedia could be seen on the Draft Namespace of Wikipedia and not main one.

📰 Article(s) of the same category(ies)

• Comparison of Java and C++
• Comparison of ALGOL 68 and C++
• Operators in C and C++
• Paraskevas Theodosiou
• BaCon (programming language)
• BCX (software)

---