Criticism of C++ - Wikipedia

## 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. As expressed by Joshua Bloch: … I think C++ was pushed well beyond its complexity threshold, and yet there are a lot of people programming it. But what you do is you force people to subset it. So almost every shop that I know of that uses C++ says, "Yes, we're using C++ but we're not doing multiple-implementation inheritance and we're not using operator overloading." There are just a bunch of features that you're not going to use because the complexity of the resulting code is too high. And I don't think it's good when you have to start doing that. You lose this programmer portability where everyone can read everyone else's code, which I think is such a good thing. Donald Knuth (1993, commenting on pre-standardized C++), who said of Edsger Dijkstra that "to think of programming in C++" "would make him physically ill": > The problem that I have with them today is that... C++ is too complicated. At the moment, it's impossible for me to write portable code that I believe would work on lots of different systems, unless I avoid all exotic features. Whenever the C++ language designers had two competing ideas as to how they should solve some problem, they said "OK, we'll do them both". So the language is too baroque for my taste. … In C++26, with the introduction of erroneous behaviour and safety improvements, some of the undefined behaviours are now compile errors such as erroneous behaviour for uninitialized reads, returning a reference for temporary variables, and deleting a pointer to an incomplete type. … 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. … `<iostream>` uses static constructors which causes overhead if included, even if the library is not used. 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. … 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: … ## Exceptions There have been concerns that the zero-overhead principle is not compatible with exceptions. 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.