[ Date Index ][
Thread Index ]
[ <= Previous by date /
thread ]
[ Next by date /
thread => ]
Nicholas John Murison wrote:
I've never quite understood how C is a bad language.
...SNIP...
The language assumes the programmer knows what he's doing.
Programmers are human they make mistakes if you leave them room
to.
The best "bad language" example was the following Fortran (I
don't have any C ones committed to memory, but I'm sure they are
around given the junk many C compilers will convert into machine
code without comment).
DO 10 I = 1.10
... perform trajectory correction calculation....
10 CONTINUE
This is (from memory) some code computing iterative trajectory
calculations on a NASA space rocket. It was intended to loop ten
times performing an iterative correction, and then the rocket
would fire it's engines according to the results of the
calculation.
The code compiled correctly, and passed manual code inspection.
The loop iterated once, which was enough in this instance to get
the rocket to it's destination without red faces at Cape
Kennedy.
The problem for those that haven't seen it before, or guessed,
is a "." instead of a ",". This means a variable "DO10I" is set
equal to "1.10", since variables starting with "D" are of type
real this is allowed.
Fortran latter supported "implicit none", and "do - end do"
constructs, and many compilers will warn of the unused variable
"DO10I", any of which advances will avoid this bug.
C suffers in similar ways to the old Fortran, additionally the
exensive reliance on pointers (Fortran was always passed
variable by reference, and made indirection harder, and
generally produced more efficient code as a result (Although
side effects were fatal - hence the classic old 2=1 fortran
bug), by restricting what programmers could say (Restricting
what you can say isn't a good thing in general)), and arcane
syntax options in C allow for much more creative typos.
Some C compilers still need motivating, or extra utilities to
identify unreachable code, spot unused results, unused variables
(Often a sign of typing mistakes), any sort of global sanity
checking on interfaces, or to invoke run time bounds checking.
Some C compilers will still allow you to use the wrong format
modifier on a variable without comment. All these things the
compilers fail to spot, are allowed syntaxes in the language,
even if they are almost invariably bugs, so if you use a
compiler that doesn't happen to spot that type of error.....
The GNU chess code I inherited had references in the code to
non-existent file handles - these compiled and ran on GCC with
maximum warnings enabled without a quibble, and apparently don't
cause a problem at run time on MOST platforms !?! Many of the
output statements didn't work correctly due to type mismatches,
when delinted the program actually gained several interesting
lines of output.
C++ is a well thought out extension to C, but a specific design
goal was backward compatibility, so anything you can do wrong in
C, you can do wrong in C++. If you write C++ the C++ way then
many of these problems (format type modifiers) go away.
Yes you can write bad code in any language, but if your goal is
precise and tight code, writing it in a language that minimises
the problems with typos, and other daft mistakes, helps
concentrate you mind on the logic.
You can use tools to help you shape you check your code, and
many different testing techniques, but if rocket scientists**
can get it wrong you want to be very conservative in what you
allow.
Simon
**I have been known to say Rocket Science isn't that hard
compared to software engineering. Rocket science being largerly
based around the conservation of momentum.
--
The Mailing List for the Devon & Cornwall LUG
Mail majordomo@xxxxxxxxxxxx with "unsubscribe list" in the
message body to unsubscribe.