Programming in C/C++

Why do people still write in C/C++? As many people have said over the years, C and C++ are sharp knives. Pointers and casts are the sharpest of the knives, and many people have run into difficult bugs in those areas. Java generally doesn’t have those problems. Why doesn’t everybody program in Java?

The obvious reason is that C/C++ code runs faster than Java code. Arguably this is less true for long running programs where the Java JIT can adjust and optimize the hot code. However, despite that argument, C and C++ still seem to be faster in practice. At the current state of the art, it may be because C/C++ programs can be hand tuned to run faster than Java programs can. If Java ever becomes consistently faster than C/C++, I imagine that many people will switch.

A less obvious reason is that it is possible to avoid the problems with C/C++ through disciplined coding. While I certainly still write buggy code, I almost never write bugs related to pointers or casts. And since pointers correspond well to the underlying processor instruction set, using them yields faster code without any special work from the compiler or the JIT.

Returning to the theme of the multi-core world, there this rule may be reversed. The open question is whether it is possible to use a disciplined approach to writing multi-core programs in C/C++. It seems clear that Java’s threading support is ahead of C/C++ in terms of ease of use and ease of writing correct programs. On the other hand, it is much less clear whether JIT techniques can be sufficiently powerful to match C/C++, if it becomes reasonably possible to write correct C/C++ parallel code.

An example of a JIT technique for parallel code is transactional memory. I expect that transactional memory will never work in the C/C++ world; it simply costs too much. It will always be possible to beat it through careful coding, and people who aren’t willing to do careful coding won’t be writing C/C++ parallel code in the first place. The future of transactional memory, if it has a future, is clearly in Java and other JIT languages. I’m surprised that the various people pushing transactional memory haven’t realized that.