To start with, there will always be some problems that are better solved in one language than another. There will always be languages that solve specific problems "better" than any other language, for some definition of "better". However, a very very large number of problems have very similar needs (some I/O, some computation) and face similar requirements (reasonable reliability, reasonable performance).
As you know C already, for the vast majority of problems out there, I state that C++ provides no significant downsides and a number of significant improvements. Bold? Some people seem to think so, but it's really the case. Let's start out by clearing up a few very common C++ misunderstandings:
C++ is slower than C. Wrong! Many C programs are valid C++ programs as well - and such a C program should run at identical speed when compiled with either the C compiler or the C++ compiler.
C++ specific features require overhead. Wrong! The so-called overhead introduced by certain C++ specific features (such as virtual function calls or exceptions), is comparable to the overhead you yourself would introduce should you implement a similar feature in C.
C++ is object oriented. Wrong! The C++ language contains some language extensions that facilitate object oriented programming and generic programming. C++ does not force object oriented design anywhere - it merely allows it. C allows for object oriented programming as well, C++ only makes it simpler and less error-prone.
So, if you believe me, we have established that "C++ is not significantly worse than C". Let's have a look at what makes C++ a better C:
Stronger typing The type system in C++ is stronger than in C. This prevents many common programming errors - coupled with the next very important feature, the stronger type system even manages not to be an inconvenience.
Parameterized types The template keyword allows the programmer to write generic (type-agnostic) implementations of algorithms. Where in C, one could write a generic list implementation with an element like:
struct element_t {
struct element_t *next, *prev;
void *element;
};
C++ allows one to write something like:
template <typename T>
struct element_t {
element_t<T> *next, *prev;
T element;
};
Not only does the C++ implementation prevent common programmer errors (like putting an element of the wrong type on the list), it also allows better optimization by the compiler! For example, a generic sort implementation is available in both C and C++ -
the C routine is defined as:
void qsort(void *base, size_t nmemb, size_t size,
int(*compar)(const void *, const void *));
whereas the C++ routine is defined as
template void sort(RandomAccessIterator first, RandomAccessIterator last);
The difference being, that for example sorting an array of integers, would, in the C case, require a function call for every single compare, whereas the C++ implementation would allow the compiler to inline the integer comparison calls, as the actual sort routine is automatically instantiated at compile time by the compiler, with the correct types inserted in the template arguments.
- A bigger standard library C++ allows the full use of the C standard library. This is very important of course, as the C standard library is an invaluable resource when writing real world programs. However, C++ includes the Standard Template Library. The STL contains a number of useful templates, like the sort routine above. It includes useful common data structures such as lists, maps, sets, etc. Like the sort routine, the other STL routines and data structures are "tailored" to the specific needs the programmer has - all the programmer has to do is fill in the types.
Of course, the STL is no silver bullet - but it does provide a great help very often, when solving general problems. How often have you implemented a list in C? How often would an RB-tree have been a better solution, if only you had had the time to do it? With the STL you do not need to make such compromises - use the tree if it's a better fit, it's as easy as using the list.
Ok, so I've only been discussing the good parts. Are there any downsides? Of course there are. However, their number is shrinking day by day. Let me explain:
There are no good C++ compilers It's been like this for a long time. But you must remember, that the language was standardized in 1998 - it is a complex language, more complex than C. It has taken a long time for compilers to catch up to the standard. But as of this writing, there are good compilers available for the most widely used platforms out there; GCC in versions 3.X are generally very good, and it runs on GNU/Linux and most UNIX platforms. Intel has a good compiler for Win32 - it is also pretty good, but unfortunately it still relies on the MS STL which is sub-par.
People don't know good C++ This is not an often heard complaint, but it's something that I see a lot. C++ is a big and complex language - but it also used to be a language that was hyped a lot, especially back in the "OOP solves hunger, cures AIDS and cancer" days. The result seems to be that a lot of really poor C++ code, basically bad C with a few class declarations here and there, is out there and is being used as learning material. This means a lot of people who believe they know C++ actually write really crappy code. That's too bad, and it's a problem, but I think it's unfair to blame this on C++.
So, the only two major problems with C++ are results of C++ being a young language. In time they will vanish. And for most problems out there, if you can get good programmers (or learn good C++ yourself), the problems are not really an issue today.
