Difference between revisions of "C++ vs. C"

From Pin Eight
Jump to: navigation, search
m (added a lead section)
(Minuses: Someone clued me in on explicit instantiation of templates; added caveat about STL implementations not supporting nothrow)
Line 18: Line 18:
 
C++ also has some features requiring possibly expensive runtime library support:
 
C++ also has some features requiring possibly expensive runtime library support:
 
* <code>throw</code>
 
* <code>throw</code>
* the default version of <code>new</code> without <code>std::nothrow</code>, which throws exceptions and is used internally by the standard library
+
* the default version of <code>new</code> without <code>std::nothrow</code>, which throws <code>std::bad_alloc</code>
 
* <code><nowiki><iostream></nowiki></code>
 
* <code><nowiki><iostream></nowiki></code>
  
 
Templates have a couple drawbacks:
 
Templates have a couple drawbacks:
* more complicated error messages
+
* Type names in error message become far more difficult to interpret.
* programmers who lose track of for how many different type combinations they have instantiated a template, causing code size to balloon
+
* 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 [http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1987.htm explicit instantiation], but you can't yet count on a C++ compiler to support this.)
  
 
Exceptions (<code>throw</code>) also have a couple drawbacks:
 
Exceptions (<code>throw</code>) also have a couple drawbacks:
Line 29: Line 29:
 
* C++ has no counterpart to the <code>finally</code> keyword of Java and Python. True, there isn't as much need for <code>finally</code> 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.
 
* C++ has no counterpart to the <code>finally</code> keyword of Java and Python. True, there isn't as much need for <code>finally</code> 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.
  
 +
The STL allows passing an allocator to all containers, but most implementations appear to assume that the allocator throws <tt>std::bad_alloc</tt> rather than returning 0 like <tt>new(std::nothrow)</tt> does.
 
Apparently one STL implementation can be built without the use of exceptions: STLPort.[http://slashdot.org/comments.pl?sid=1708154&cid=32799808]
 
Apparently one STL implementation can be built without the use of exceptions: STLPort.[http://slashdot.org/comments.pl?sid=1708154&cid=32799808]
 
I'd be interested to hear about whether it has worked for you.
 
I'd be interested to hear about whether it has worked for you.

Revision as of 18:07, 5 July 2010

Over a decade after the 1998 standardization of the C++ programming language, the C++ vs. C debate continues.

Pluses

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:

  • namespace
  • references
  • function overloading
  • type-safe new(std::nothrow)
  • STL, the part of the C++ standard library with containers and algorithms
  • non-virtual methods

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
  • virtual methods, when compared to C function pointer tables
  • templates instantiated several times, when compared to using the preprocessor to instantiate multiple copies

Minuses

C++ also has some features requiring possibly expensive runtime library support:

  • throw
  • the default version of new without std::nothrow, which throws std::bad_alloc
  • <iostream>

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.)

Exceptions (throw) also have a couple drawbacks:

  • The size of the required library support might cause a problem on embedded or handheld devices with little RAM.
  • C++ has no counterpart to the finally keyword of Java and Python. 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.

The STL allows passing an allocator to all containers, but most implementations appear to assume that the allocator throws std::bad_alloc rather than returning 0 like new(std::nothrow) does. Apparently one STL implementation can be built without the use of exceptions: STLPort.[1] I'd be interested to hear about whether it has worked for you.

The <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 <cstring> and <cstdio> instead of new-fangled <string> and <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.

External links

  • C++ FQA Lite, offering a rebuttal to the fandom's C++ FAQ Lite