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

From Pin Eight
Jump to: navigation, search
(Pluses: Technically, operator methods are separate functions)
m (Minuses: In case someone doesn't have a copy of EC++ 2e around)
Line 15: Line 15:
 
* <code>virtual</code> methods, when compared to C function pointer tables, especially the pure virtual method's undefined behavior that some compilers may implement as an exception
 
* <code>virtual</code> methods, when compared to C function pointer tables, especially the pure virtual method's undefined behavior that some compilers may implement as an exception
 
* templates instantiated several times, when compared to using the preprocessor to instantiate multiple copies
 
* templates instantiated several times, when compared to using the preprocessor to instantiate multiple copies
 +
 +
PROTIP: A <code>class</code> is a <code>struct</code> whose first member is <code>private</code>.
 +
That's the only difference.
  
 
== Minuses ==
 
== Minuses ==
Line 37: Line 40:
 
The <code><nowiki><iostream></nowiki></code> library is another divisive issue.
 
The <code><nowiki><iostream></nowiki></code> library is another divisive issue.
 
It was envisioned as a type-safe alternative to <code><nowiki><cstdio></nowiki></code>, but implementations are [http://yosefk.com/c++fqa/io.html hairy], [http://www.pineight.com/rant/#cbloatbloat bloated], [http://www.vterrain.org/Implementation/effective.html inefficient].
 
It was envisioned as a type-safe alternative to <code><nowiki><cstdio></nowiki></code>, but implementations are [http://yosefk.com/c++fqa/io.html hairy], [http://www.pineight.com/rant/#cbloatbloat bloated], [http://www.vterrain.org/Implementation/effective.html inefficient].
Yet some C++ fanboys claim that anything using good old <code><nowiki><cstring></nowiki></code> and <code><nowiki><cstdio></nowiki></code> instead of new-fangled <code><nowiki><string></nowiki></code> and <code><nowiki><iostream></nowiki></code> isn't in the spirit of C++, [[wikipedia:no true Scotsman|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 <code><nowiki><iostream></nowiki></code> is imperfect and removed item 2 from the third edition.
+
Yet some C++ fanboys claim that anything using good old <code><nowiki><cstring></nowiki></code> and <code><nowiki><cstdio></nowiki></code> instead of new-fangled <code><nowiki><string></nowiki></code> and <code><nowiki><iostream></nowiki></code> isn't in the spirit of C++, [[wikipedia:no true Scotsman|whatever that means]]. They cling to item 2 in the second edition of Scott Meyers' ''Effective C++'', which promotes <code><nowiki><iostream></nowiki></code> over <code><nowiki><cstdio></nowiki></code>, and ignore item 23 of his sequel ("consider alternative libraries"). It appears that Meyers eventually recognized that <code><nowiki><iostream></nowiki></code> is imperfect and removed item 2 from the third edition.
  
 
== External links ==
 
== External links ==
 
*[http://yosefk.com/c++fqa/ C++ FQA Lite], offering a rebuttal to the fandom's C++ FAQ Lite
 
*[http://yosefk.com/c++fqa/ C++ FQA Lite], offering a rebuttal to the fandom's C++ FAQ Lite

Revision as of 21:38, 25 August 2010

This is a mini-rant, a short essay refuting a common misconception among users of an Internet forum. If you think this essay is FUD, feel free to explain why on the essay's talk page.

The C++ programming language brings improvements over its predecessor C, but fans of other languages point out that C++ is still not perfect. 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:

  • namespaces
  • function overloading
  • type-safe new(std::nothrow)
  • STL, the part of the C++ standard library with containers and algorithms
  • non-virtual methods
  • 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 ordinary function-call syntax
  • virtual methods, when compared to C function pointer tables, especially the pure virtual method's undefined behavior that some compilers may implement as an exception
  • templates instantiated several times, when compared to using the preprocessor to instantiate multiple copies

PROTIP: A class is a struct whose first member is private. That's the only difference.

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. Common implementations may expand a template type name fully in diagnostic messages even if the source code accesses the type through a typedef. For example, an error message involving the std::string type is likely to provoke this reaction: "basic_string? I'm using C++, not BASIC! And what the fsck is char_traits?" (True, implementations are not the language, but a language is only as good as its best free implementation.)
  • Programmers can lose track of for how many different type combinations they have instantiated a template, causing code size to balloon. There is a common extension called extern template allowing for explicit instantiation, but it's not in C++98, and not all compilers support it.

Exceptions (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++98 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. C++0x addresses this by letting the programmer build a scope-guard with std::shared_ptr and lambda expressions.

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.[1] 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, 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++, which promotes <iostream> over <cstdio>, 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