[an error occurred while processing this directive] [an error occurred while processing this directive]
Imagine you are a construction worker, and your boss tells you to connect the gas pipe in the basement to the street's gas main. You go downstairs, and find that there's a glitch; there isn't yet any interior gas pipe. Perhaps you do nothing, or perhaps you decide to attach the gas main to the only existing attachment in sight -- the air intake. Either way, suppose you report back to your boss that you're done.
This results in an explosion, and you'd be guilty of criminal negligence.
Yet this is exactly what happens in many computer languages.
In C/C++, the programmer (boss) can write
37 * "hello"
(one which may vary each time the program runs!),
multiplies by 37, and merrily reports the result,
without any hint of a problem.
[Based on an example by
In a world where programs control
my personal finances,
it is criminal negligence to use a language with the flaws of C/C++.
Even for games, browsers, and spreadsheets,
the use of C/C++ needlessly abets inflicting bugs on the
This is only one example of how C and C++ get some of the basics wrong.
Even the authors of the
definitive C++ Annotated Reference Manual (“ARM”)
confess that there are problems with the basics; for example:
“the C array concept is weak and beyond repair” [pg 212].
I highly recommend
i = v[i++], the final value of
iis undefined [C++ ARM, p.46]. It's not difficult for a language to warn you if you write this, but no C++ compilers choose to.
[The full version of this page, with links, is at http://www.cs.rice.edu/~ian/Manifestoes/whyC++isBad.shtml.]
Given these known flaws with C/C++, why is there the popular misconception -- among too many programmers and public alike -- that C++ is a good language? I genuinely am at a loss to explain it. But here's my suspicion: When C/C++ programmers, used to walking the tightrope without a net, see that a language like Java or Scheme is doing extra work (verifying that any additions really are given numbers instead of strings, making sure arrays indices are legal, etc.), their reaction is “ugh, the computer is doing so much extra work, my programs will run too slow!” Indeed, benchmark programs do run faster in C or C++.
But there are a number of things to keep in mind: It is well-documented that development time is much longer in C/C++, since bugs creep in more easily. Hence, cost is also higher for C/C++ programs. (Many C/C++ projects have never been completed because of obscure memory bugs.) I'd rather have a slower, correct program than one which finds a wrong answer more quickly :-).
Or even, how important is it to have fast programs? I don't know about you, but when i think about it, most of my wait-time behind the computer is due to my slow typing, or thinking, or waiting for info to download. I've spent much less time waiting for a calculation to finish than i have waiting for my computer to re-boot, or re-typing data which was lost because of a crash.
For some applications -- voice recognition, drafting, some types of graphics (not mere video playback/editing), modeling nuclear explosions -- speed is critical. And expert programmers using C/C++² for those situations is fine. Myself, I rarely or never run those types of programs; more pertinently, I've certainly never had the need to write any myself.
After talking repeatedly with people who tout C++'s run-time efficiency while dismissing its lack of safety, I've seen that they often have a couple of other attitudes:
For a much more detailed argument on the shortcomings of C and C++, see Ian Joyner's C++?? : A Critique of C++ [http://www.elj.com/cppcv3/], which includes examples of both flaws inherited from C and flaws introduced in C++. For example, he correctly points out that constructs like:
// s1, s2 are char* // (intended as strings, not ptrs to an individual char). while (*s1++ = *s2++);might look optimal to C programmers, but are the antithesis of efficiency. Such constructs preclude compiler optimisation for processors with specific string handling instructions. A simple assignment is better for strings, as it will allow the compiler to generate optimal code for different target platforms. If the target processor does not have string instructions, then the compiler should be responsible for generating the above loop code, rather than requiring the programmer to write such low level constructs. The above loop construct for string copying is contrary to safety, as there is no check that the destination does not overflow, again an undetected inconsistency which could lead to obscure failures. The above code also makes explicit the underlying C implementation of strings, that are null terminated. Such examples show why C cannot be regarded as a high level language, but rather as a high level assembler.
¹ Java, while much better than C++, shares this same weakness: the smallest Java program requires about 12 keywords, each replete with meaning; a beginner must be told "put these words in your program in just this right order, else it won't work". I've seen many students needlessly frustrated because it takes 30min to figure out their non-working program resulted from only inscribing eleven of the dozen necessary arcane glyphs. They may understand conceptually exactly what they want to do, but the arbitrary details of excessive syntax take out all the interest. (Some studies suggest that the prevalent teaching mode -- encouraging arbitrary tinkering with little direction or meaning just trying to get it to work -- is one reason for the prounounced gender bias seen in the field of computer science.) Any teacher knows not to distract from a topic by introducing advanced details to a beginner. Common sense? You wouldn't know it from all the people who want to teach intro programming, but then use Java to do so. (back)
² Indeed, any professional programmer who uses C++ will tell you that they use a disciplined subset of it, since without self-imposed guidelines it's easy to hang yourself with some of the language's "features". (back)[an error occurred while processing this directive]