Criticism of C++

C++ is a general-purpose programming language with imperative, object-oriented and generic programming features. Many criticisms have been leveled at the programming language from, among others, prominent software developers like Linus Torvalds,[1] Richard Stallman,[2] and Ken Thompson.[3]

C++ is a multiparadigm programming language[4] with backward compatibility with the programming language C.[5] 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 of them being 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 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 extremely slow to compile.[7]

One solution for this is to use the Pimpl idiom. By using pointers on the stack to the implementation object on the heap there is a higher chance all object sizes on the stack become equal. This of course comes with the cost of an unnecessary heap allocation for each object. Additionally precompiled headers can be used for header files that are fairly static.

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

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

The global state of <iostream> uses static constructors which causes overhead.[10] Another source of bad performance is the use of std::endl instead of '\n' when doing output, because of it calling flush as a side effect. C++ <iostream> is by default synchronized with <stdio.h> 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: 

#include <iostream>
#include <vector>

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

It is acknowledged even by some members of the C++ standards body[11] 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.

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.[12] 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.[13][14] 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.[15][16] 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[17] 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.[18]

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. Iterators are hard to implement efficiently which caused Alexander Stepanov to blame some compiler writers for their initial weak performance.[19] The complex categories of iterators have also been criticized,[20][21] and ranges have been proposed for the C++ standard library.[22]

One big problem is that iterators often deal with heap allocated data in the C++ containers and becomes 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.[23][24] 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:

#include <iostream>
#include <string>

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

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[25][26]

#include <iostream>
#include <vector>

int main() {
    int integer1{10}; // int
    int integer2(10); // int
    std::vector<int> vector1{10,0}; // std::initializer_list
    std::vector<int> vector2(10,0); // size_t,int
    
    std::cout << "Will print 10" 
    << std::endl << integer1 << std::endl;
    std::cout << "Will print 10" 
    << 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 << ',';

    return(EXIT_SUCCESS);
}

Exceptions

There have been concerns that the zero-overhead principle[27] isn't compatible with exceptions.[28] Most modern implementation has a zero performance overhead when exceptions are enabled but not used, but instead has an overhead in exception handling and in binary size due to the need for 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,[29] 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 the array length has little to do with the string length in code points. There is no support for advanced Unicode concepts like normalization, surrogate pairs, bidi or conversion between encodings.

This will print out the length of two strings with the equal amount of Unicode code points:

#include <iostream>
#include <string>
#include <cassert>

int main() {
    // This will print "22 18", 
    // 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 << utf8.length() << " " << ascii.length() << std::endl;
    assert(utf8.length() == ascii.length()); // Fail!
    return(EXIT_SUCCESS);
}

Verbose assembly and code bloat

For a long time, there have been accusations about C++ generating code bloat.[30][31]

See also

References

  1. ↑ "Re: [RFC] Convert builin-mailinfo.c to use The Better String Library" (Mailing list). 6 September 2007. Retrieved 31 March 2015.
  2. ↑ "Re: Efforts to attract more users?" (Mailing list). 12 July 2010. Retrieved 31 March 2015.
  3. ↑ Andrew Binstock (18 May 2011). "Dr. Dobb's: Interview with Ken Thompson". Retrieved 7 February 2014.
  4. ↑ "What is "multiparadigm programming"?".
  5. ↑ "Are there any features you'd like to remove from C++?".
  6. ↑ Walter Bright. "C++ compilation speed".
  7. ↑ Rob Pike. "Less is exponentially more". Back around September 2007, I was doing some minor but central work on an enormous Google C++ program, one you've all interacted with, and my compilations were taking about 45 minutes on our huge distributed compile cluster.
  8. ↑ "A Module System for C++" (PDF).
  9. ↑ "iostream state saver".
  10. ↑ "#include <iostream> is Forbidden".
  11. ↑ "N4412: Shortcomings of iostreams". open-std.org. Retrieved 2016-05-03.
  12. ↑ "A Conversation with Bjarne Stroustrup".
  13. ↑ "std::vector".
  14. ↑ "std::string".
  15. ↑ "A Conversation with Bjarne Stroustrup". I think a better way of approaching C++ is to use some of the standard library facilities. For example, use a vector rather than an array. A vector knows its size. An array does not... Most of these techniques are criticized unfairly for being inefficient. The assumption is that if it is elegant, if it is higher level, it must be slow. It could be slow in a few cases, so deal with those few cases at the lower level, but start at a higher level. In some cases, you simply don't have the overhead. For example, vectors really are as fast as arrays.
  16. ↑ Bjarne Stroustrup. "Why are the standard containers so slow?". People sometimes worry about the cost of std::vector growing incrementally. I used to worry about that and used reserve() to optimize the growth. After measuring my code and repeatedly having trouble finding the performance benefits of reserve() in real programs, I stopped using it except where it is needed to avoid iterator invalidation (a rare case in my code). Again: measure before you optimize.
  17. ↑ "boost::array". As replacement for ordinary arrays, the STL provides class std::vector. However, std::vector<> provides the semantics of dynamic arrays. Thus, it manages data to be able to change the number of elements. This results in some overhead in case only arrays with static size are needed.
  18. ↑ Scott Meyers. "std::string, SSO, and Move Semantics". Case in point: std::string. It supports moves, but in cases where std::string is implemented using SSO (the small string optimization), small strings are just as expensive to move as to copy! What it means to be "small" is up to the implementation. Unless I'm misreading the source files, std::strings with a capacity of up to 15 are "small" in Visual C++ 11 beta, so std::string objects of up to that capacity will not benefit when copies become moves. (The SSO buffer size seems to be hardwired to be 16 bytes in VC11, so the maximum capacity of a std::wstring that fits in the SSO buffer is smaller: 7 characters.)
  19. ↑ Alexander Stepanov. "Stepanov Benchmark". The final number printed by the benchmark is a geometric mean of the performance degradation factors of individual tests. It claims to represent the factor by which you will be punished by your compiler if you attempt to use C++ data abstraction features. I call this number "Abstraction Penalty." As with any benchmark it is hard to prove such a claim; some people told me that it does not represent typical C++ usage. It is, however, a noteworthy fact that majority of the people who so object are responsible for C++ compilers with disproportionately large Abstraction Penalty.
  20. ↑ Andrei Alexandrescu. "Iterators Must Go" (PDF).
  21. ↑ Andrei Alexandrescu. "Generic Programming Must Go" (PDF).
  22. ↑ Eric Niebler. "Ranges for the Standard Library".
  23. ↑ Scott Meyers. Effective STL. Given all that allocation, deallocation, copying, and destruction. It should not stun you to learn that these steps can be expensive. Naturally, you don't want to perform them any more frequently than you have to. If that doesn't strike you as natural, perhaps it will when you consider that each time these steps occur, all iterators, pointers, and references into the vector or string are invalidated. That means that the simple act of inserting an element into a vector or string may also require updating other data structures that use iterators, pointers, or references into the vector or string being expanded.
  24. ↑ Angelika Langer. "Invalidation of STL Iterators" (PDF).
  25. ↑ Scott Meyers. "Thoughts on the Vagaries of C++ Initialization".
  26. ↑ "Do not use Braced Initializer Lists to Call a Constructor".
  27. ↑ Bjarne Stroustrup. "Foundations of C++" (PDF).
  28. ↑ "Do not use RTTI or Exceptions".
  29. ↑ Stroustrup 1994, 16.5 Resource Management, pp. 388–89.
  30. ↑ "Why is the code generated for the "Hello world" program ten times larger for C++ than for C?". It isn't on my machine, and it shouldn't be on yours. I have even seen the C++ version of the "hello world" program smaller than the C version. In 2004, I tested using gcc -O2 on a Unix and the two versions (iostreams and stdio) yielded identical sizes. There is no language reason why the one version should be larger than the other. It is all an issue on how an implementor organizes the standard libraries (e.g. static linking vs. dynamic linking, locale support by default vs. locale support enabled through and option, etc.). If one version is significantly larger than the other, report the problem to the implementor of the larger.
  31. ↑ Adrian Stone. "Minimizing Code Bloat: Template Overspecialization".

Further reading

External links

This article is issued from Wikipedia - version of the 10/6/2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.