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.

2 Comments »

  1. wh5a said,

    December 21, 2007 @ 12:24 am

    You made an interesting point. I got two questions below.
    1. I understand that coding disciplines can help eliminate pointer bugs. But is parellism understood well enough by us to give a good discipline?

    2. What do you think of functional programming languages?

  2. Ian Lance Taylor said,

    December 21, 2007 @ 7:30 am

    Thanks for the note.

    I don’t think parallelism is understood well enough. I’ve made a couple of posts on this in the past.

    I used to work on functional languages. I like them. They are one way to nicely solve the parallelism problem. But I worked on functional languages over twenty years ago, in school, and even back then they were being touted as a solution to parallel programming. The fact that very few people outside of academics are writing code in functional languages pretty much proves to me that they are not the solution to anything. If they were, they would be used.

    I wrote about this before too, back in October.

RSS feed for comments on this post · TrackBack URI

You must be logged in to post a comment.