C++ vs. C

From Pin Eight
Jump to: navigation, search






  • namespaces
  • function overloading
  • type-safe new(std::nothrow)
  • non-virtual methods
  • references, needed by operator overloading


  • operator overloading, when compared to ordinary function-call syntax




  • throw
  • <iostream>


Templates have a couple drawbacks:

  • Programmers can lose track of for how many different type combinations they have instantiated a template, causing code size to balloon. There is a new feature in C++11 called extern template allowing for explicit instantiation, but not all compilers support it yet.


Exceptions (throw) also have a few drawbacks:

  • Some platforms require different stack frame formats for code that uses exceptions and code that does not use exceptions. Unless you completely disable exception support using compiler flags, the exception support may still eat up a few percent of CPU time, roughly 8 to 10 percent in GCC.[1]
  • Even if you have determined that a particular compiler imposes little to no runtime speed penalty for exceptions, the size of the required library support might cause a problem on embedded or handheld devices with less than about a megabyte of RAM. I'll grant that this has become somewhat less important in the 2010s as the market has transitioned from handheld devices with 384 KiB of RAM, such as a Game Boy Advance, to smartphones with a thousand times that much memory.
  • A practical counterpart to the finally keyword of Java and Python was not added until C++11. True, there isn't as much need for finally in C++ as in languages that rely on a garbage collector, given the idiom of allocating resources in constructors that C++'s deterministic destruction allows. But a method often still needs to restore the object's fields to a consistent state before eating or rethrowing the exception. Once compilers implement C++11, however, the programmer can build a scope-guard with std::shared_ptr and lambda expressions.
  • If a function throws exceptions, all callers have to be aware of all exception types that it may throw, and all callers have to be written in C++ using exception style so that they can catch the exceptions. And unlike Java with its checked exceptions, C++ compilers offer no built-in automated tests to ensure that a method either handles or rethrows exceptions that its callees throw. This is one reason why Google is not a fan of C++ exceptions.[1]

On platforms without virtual memory, a program must be aware of possible out-of-memory conditions. The STL allows passing an allocator to all containers, but most implementations appear to exhibit undefined behavior when allocate() returns 0 like new(std::nothrow) does. I've been told one STL implementation can be built with nothrow in mind: STLPort.[2][3] EA Games created an out-of-memory-aware allocator.


The <iostream> library is another divisive issue. It was envisioned as a type-safe alternative to <cstdio>, but implementations are hairy, convoluted, bloated, and inefficient. This goes double if you have to use a statically linked implementation of the C++ standard library, either because the operating system provides no C++ standard library (e.g. handheld video game systems) or because your compiler's C++ ABI differs from that of the operating system publisher's own development tools (e.g. MinGW). Hello World programs with -Os and statically linked libstdc++ in one version of MinGW resulted in 5,632 bytes for <cstdio> but 266,240 bytes for <iostream>. A devkitARM project targeting Game Boy Advance had similar results: 5,156 bytes for C-style I/O and 253,652 bytes for <iostream>. (This is expected; Thumb and x86 have comparable code density.) Even removing some unreachable code with -Wl,-gc-sections couldn't get the GBA project below 180,032 bytes. (For comparison, the GBA's main RAM is 262,144 bytes.) These tests are with GNU libstdc++, which initializes date, time, and money aspects of a locale for each stream even if the program never shifts a date, time, or money object into the stream. This is because it was conceived before templates and instead uses virtual inheritance and "facets", which C++ implementations can't optimize well.[4] Some third-party C++ standard library implementations such as uClibc++ are designed for space efficiency and leave out features such as locale support that aren't as useful in small-memory systems. In fact, one C++ advocate claims that comparing memory usage of C++ to C by targeting a sub-megabyte platform with GNU libstdc++ sets up a huge straw man.[5]




  1. Andrew Binstock. "The Scourge of Error Handling". Dr. Dobb's, 2012-12-05. Accessed 2012-12-08.

External links

Personal tools