1. Slow compile times

2. Global format state of

3. Heap allocations in containers

4. Iterators

5. Uniform initialization syntax

6. Exceptions

7. Strings without Unicode

8. Code bloat

9. See also

10. References
     Works cited 

11. Further reading

12. External links

Some of the problems might be related to the compiler used and not the language itself.}}

C++ is a multi-paradigm programming language^[9] with extensive, but not complete, backward compatibility with C.^[10] This article focuses not on C features like pointer arithmetic, operator precedence or preprocessor macros, but on pure C++ features that are often criticized.

Slow compile times

The natural interface between source files in C/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.^[11] 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 are not only exposing their public variables and public functions (like C with its structs and function prototypes) but also their private functions. This forces unnecessary recompiles of all source files that include the header file, each time when changing these private functions. 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 the whole C++ standard library. Large C++ projects can therefore be relatively slow to compile.^[12] The problem is largely solved by precompiled headers in modern compilers.

One suggested solution is to use a module system.^[13]

Global format state of

C++ unlike C 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 Boost^[14] but is not a part of the C++ Standard Library.

The global state of uses static constructors which causes overhead.^[15] Another source of bad performance is the use of std::endl instead of '\' when doing output, because of it calling flush as a side effect. C++ is by default synchronized with which can cause performance problems. Shutting it off can improve performance but forces giving up thread safety.

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 isn't what one wants:

1. include
2. include

int main() {

    try {        std::cout << std::hex;        std::cout << 0xFFFFFFFF << std::endl;        std::vector vector(0xFFFFFFFFFFFFFFFFL,0); // Exception        std::cout << std::dec; // Never reached    } catch(std::exception &e) {        std::cout << "Error number: " << 10 << std::endl; // Not in decimal    }

}

It is acknowledged even by some members of the C++ standards body^[16] that the iostreams interface is an aging interface that needs to be replaced eventually. This design forces the library implementers to adopt solutions that impact performance greatly.{{citation needed|date=June 2016}}

Heap allocations in containers

After the inclusion of the STL in C++, its templated containers were promoted while the traditional C arrays were strongly discouraged.^[17] One important feature of containers like std::string and std::vector is them having their memory on the heap instead of on the stack like C arrays.^[18][19] To stop them from allocating on the heap, one would be forced to write a custom allocator, which isn't standard. Heap allocation is slower than stack allocation which makes claims about the classical C++ containers being "just as fast" as C arrays somewhat untrue.^[20][21]{{failed verification|date=June 2016}}{{synthesis inline|date=June 2016}} They are just as fast to use, but not to construct. One way to solve this problem was to introduce stack allocated containers like boost::array^[22] or std::array.

As for strings there is the possibility to use SSO (short string optimization) where only strings exceeding a certain size are allocated on the heap. There is however no standard way in C++ for the user to decide this SSO limit and it remains hard coded and implementation specific.^[23][24]{{acn|date=June 2016}}

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.^[25] The interface using pairs of iterators to denote ranges of elements has also been criticized,^[26][27] and ranges have been proposed for the C++ standard library.^[28]

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.^[29][30] 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:

1. include
2. include

int main() {

    std::string text = "One\Two\Three\Four\";    // Let's add an '!' where we find newlines    for(auto i = text.begin(); i != text.end(); ++i) {        if(*i == '\') {            // i =             text.insert(i,'!')+1;             // Without updating the iterator this program has             // undefined behavior and will likely crash        }    }               std::cout << 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. This can be confusing for beginners and experts alike^[31][32]

1. include
2. include

int main() {

    int integer1{10}; // int    int integer2(10); // int    std::vector vector1{10,0}; // std::initializer_list    std::vector vector2(10,0); // size_t,int        std::cout << "Will print 10" 

<< std::endl << integer1 << std::endl;

<< std::endl << integer2 << std::endl;

        std::cout << "Will print 10,0," << std::endl;    for(auto &i : vector1) std::cout << i << ',';    std::cout << std::endl;    std::cout << "Will print 0,0,0,0,0,0,0,0,0,0," << std::endl;    for(auto &i : vector2) std::cout << i << ',';

}

Exceptions

There have been concerns that the zero-overhead principle^[33] isn't compatible with exceptions.^[34] 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,{{sfn|Stroustrup|1994|loc=16.5 Resource Management, pp. 388–89}} which has proven useful beyond making C++ exceptions safe.

Strings without Unicode

The C++ Standard Library offers no real support for Unicode. std::basic_string::length will only return the underlying array length which is acceptable when using ASCII or UTF-32 but not when using variable length encodings like UTF-8 or UTF-16. In these encodings, array length is neither a correct measure of the number of code points, number of characters or width. There is no support for advanced Unicode concepts like normalization, surrogate pairs, bidi or conversion between encodings, although unicode libraries exist to handle these issues, such as iconv and ICU.

The example below prints the lengths of two equally long strings. The strings are equally long in characters, but the program takes their lengths in bytes. If the program's source code is saved in a constant width character set like ISO-8859-1, both strings come out as 18 bytes, but in UTF-8, the first string becomes either 22 or 26 bytes depending on unicode normalization.

1. include
2. include

int main() {

    // UTF-8 prefix just to be explicit    std::string utf8  = u8"Vår gård på Öland!";    std::string ascii = u8"Var gard pa Oland!";    std::cout << "length of «" << utf8  << "» = " << utf8 .length() << '\';    std::cout << "length of «" << ascii << "» = " << ascii.length() << '\';

}

Code bloat

Some older implementations of C++ have been accused of generating code bloat.^[35]{{rp|177}}

See also

• Most vexing parse
• Criticism of object-oriented programming
• Diamond inheritance problem
• Advantages and disadvantages of templates over macros
• Function overloading complications
• Late binding criticism
• Operator overloading criticism
• Exception handling criticism
• Argument dependent name lookup criticism
• Feature creep
• Gotcha (programming)
• Object slicing

References

Works cited

• {{Cite book | isbn = 0-201-54330-3 | title = The Design and Evolution of C++ | last = Stroustrup | first = Bjarne | authorlink = Bjarne Stroustrup | year = 1994 | publisher = Addison-Wesley | ref = harv}}

Further reading

• {{cite book|author=Ian Joyner|title=Objects Unencapsulated: Java, Eiffel, and C++?? (Object and Component Technology)|publisher=Prentice Hall PTR; 1st edition|date=1999|isbn=978-0130142696}}
• {{cite book|author=Peter Seibel|title=Coders at Work: Reflections on the Craft of Programming|publisher=Apress|date=2009|isbn=978-1430219484}}

External links

• C++ FQA Lite by Yossi Kreinin
• C++ The COBOL of the 90s
• [https://gigamonkeys.wordpress.com/2009/10/16/coders-c-plus-plus/ 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

• Natsumi Matsubara
• Natsumi Murakami
• Natsumi Temple complex
• Natsumi Templesite
• Natsumi Tsuji
• Natsu no arashi
• Natsu No Arashi
• Natsu no Arashi
• Natsu no Arashi! Akinai chū
• Natsu no Umi
• Natsu no Yoru wa Danger!
• Natsu no Yutsu (Time to Say Goodbye)
• Natsu no Yuutsu ~Time to Say Goodbye~
• Natsushima class minelayer
• Natsushima-class minelayer (1933)
• Nats Xtra
• Natsy
• Natsöderblom
• Natta!
• Natta, Benin
• Nat Taggart
• Nattai
• Nattai River
• Natta Konysheva
• Nattalin Township