C++ vs. C
Over a decade after the 1998 standardization of the C++ programming language, the C++ vs. C debate continues.
Compared to C, C++ has a bunch of new language features with little or no runtime overhead because they are translated to code equally as efficient as the equivalent C code:
- function overloading
- STL, the part of the C++ standard library with containers and algorithms
- references, needed by operator overloading
A few features are as efficient as C yet still rawther deceptive and easy to misuse because the "simple" syntax hides how much code is actually being generated:
- operator overloading, when compared to separate functions
virtualmethods, when compared to C function pointer tables
- templates instantiated several times, when compared to using the preprocessor to instantiate multiple copies
C++ also has some features requiring possibly expensive runtime library support:
- the default version of
std::nothrow, which throws
Templates have a couple drawbacks:
- Type names in error message become far more difficult to interpret.
- Programmers can lose track of for how many different type combinations they have instantiated a template, causing code size to balloon. (The next C++ standard should include explicit instantiation, but you can't yet count on a C++ compiler to support this.)
throw) also have a couple drawbacks:
- Though exceptions have little to no runtime speed penalty in a modern C++ compiler, the size of the required library support might cause a problem on embedded or handheld devices with less than about a megabyte of RAM.
- C++ has no counterpart to the
finallykeyword of Java and Python. True, there isn't as much need for
finallyin 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.
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.
I'd be interested to hear about whether it has worked for you.
<iostream> library is another divisive issue.
It was envisioned as a type-safe alternative to
<cstdio>, but implementations are hairy, bloated, inefficient.
Yet some C++ fanboys claim that anything using good old
<cstdio> instead of new-fangled
<iostream> isn't in the spirit of C++, whatever that means. They cling to item 2 in the second edition of Scott Meyers Effective C++ and ignore item 23 of his sequel ("consider alternative libraries"). It appears that Meyers eventually recognized that
<iostream> is imperfect and removed item 2 from the third edition.
- C++ FQA Lite, offering a rebuttal to the fandom's C++ FAQ Lite