CPaMA 1Ed - Page 001 to 008 - 02.33% Completion
1 Introducing C
In his introduction King relates how C was a by-product of the UNIX operating system. They were both developed at Bell laboratories by Ken Thompson, Dennis Ritchie, and others, starting in 1969.
1.1 History of C
Origins
King describes how, originally, UNIX was written in assembly, for one type of machine, and how the Bell Labs team felt the OS had to be re-written in a higher-level language in order to make it easily expandable, improvable, and portable, to newer, more powerful, microcomputers.
Working on the PDP-7 and later the PDP-11, they first used a higher-level language invented by Ken, B, which was based on BCPL, which was, in turn, based on ALGOL 60. Later Ritchie began programming the PDP-7 in B too, a'nd when the company in 1970 bought a PDP-11, it was soon felt that B in it's current state wouldn't cut it, so Ritchie began to expand the language. They first labeled this version New B (NB), and as it started to diverge too significantly from original B, they changed it's name to C.
In 1973 the language was stable enough to rewrite UNIX with it. By being written in C UNIX became portable to any system that had a C compiler written for it (in assembly). In this manner Bell Labs could port UNIX to all computer systems they had on the companies floor.
Standardization
Next King talks about the maturation of C during the seventies and the publication of the classic first C book, in 1978: 'The C Programming Language' by Dennis Ritchie and Brian Kernighan, known as K&R or the 'White Book'. This book created the de facto first C standard: K&R C.
He also describes how C programmers at the end of the 1970's were a small group that were also UNIX users, but that during the 1980's this group grew beyond the confines of the UNIX OS community. Other systems began to have C compilers, especially the IBM-PC system.
During the 1980's alsp Atari, Amiga, Macintosh and CoCo had C compilers and C IDE's.
Because the K&R was not crystal clear about certain aspects of the language, and was still oriented at the UNIX OS, developers of other systems programmed their assemblers according to their own interpretation, filling in gaps by themselves etc, thus causing slight differences between compilers and platforms. Over the years innovative c programmers also removed, added and replaced features at will. This harmed the compatibility and portability of the C language and turned C overall into a messy language.
This messiness was cause for the ANSI, the since 1911 well established American National Standards Institute, to develop the first official standard, which became approved in 1989 as ANSI X3.159-1989, and which is generally known as ANSI C or C89.
In1990 the language also became approved by the ISO, a newer international IT specific standardization organization. This version is labeled ISO/IEC 9899-1990, also called C90.
King states that C90 is the standard used in this book.
C++King describes how, although C itself did not change since the C90 standard,
(from the standpoint of 1996)
it has brought forth a few close descendants (and many less close)
- Concurrent C
- Objective-C
- C++
Of these 3, C++, created by Bjarne Stroustrup, also working at Bell Labs, has been the most successful and is rapidly growing.
(in 1996)
He goes on explaining how C++, in particular, brings object-oriented programming to the table. King poses the question: if we have a more advanced version of C, C++, then why use C at all?
Reasons he gives for first learning C:
- C++ is much harder to learn
- best to learn C before tackling C++ or any other languages secondarily derived from C
- there is a lot of C code around and there is a big chance we will have to deal with it, no matter our language of choice
- not everyone will move to C++, especially for smaller programs it is not beneficial to use c++
Reasons he lists to learn C++ first
- avoiding to pick up C habits that do not work in c++
He goes on to explain that this book avoids this problem by emphasizing data abstraction, information hiding and others principles of C that are also important in C++. He says that C++ contains all of C so everything that one learns from this book also works in C++.
I have to add that a lot has changed since 1996 and C++ has diverged so much from C that it has became counterproductive to combine them as if they were one language. Some people do this and the practice is called C/C++. But contemporary C and C++ programmers in general seem to reject this approach and prefer to treat both as entirely separated languages.
Personally I also prefer the latter and so I would have preferred if this book would not have taken in account compatibility between C and C++, and focused on C as if C++ did not exist, but it is understandable that King saw it this way back in 1996, since C++ was still closer to C back then and largely seen as an extension of C.
1.2 Strengths and weaknesses of CGeneral properties
- C is a low-level language.
It is well suited to be used in unison with assembly and to direct computer components directly. Compared to machine language and assembly C is high level, but it is the most low-level of all high-level languages, so to speak.
- C is a small language.
To keep itself small it 's features rely on a library of standard functions
- C is permissive, giving more freedom than many other languages
Strengths
- efficiency:
doing much with little resources
- portability:
system-agnostic
- power:
much effect with few lines
- flexibility
can be used for many types of applications
- relies on a standard library with ready made functions that can be called upon
- integration with UNIX: is particularly powerful when used with UNIX, for which it was originally developed
Probably this goes for Linux too, in this time and age, since it is an open source clone of UNIX.
C's strengths and weaknesses come from its low-level character says KING
Weaknesses
- C programs can be error-prone, due to its flexibility.
C compilers will filter less errors than some other languages
- C programs can be less readable for non c programmers.
The syntax is aimed at efficiency rather than readability. And due to its flexibility, if a programmer is not careful his program can become like a mystical jungle easily
- Not easy to modify a larger c program if the programmer does not pay sufficient attention to structure and future maintenance.
Many modern languages 'force' the programmer to follow a structure that helps later modification, but in C this is the responsibility of the programmer to do himself and it i easy to mess this up.
Effective Use of C
To use C effectively, King states, the programmer must take advantage of C's strengths while avoiding its weaknesses.
- learn how to avoid C pitfalls
- use software tools to make C programs more reliable:.
King advises to use lint' or a similar debugging program for extra error detection in addition to the compiler.
- take advantage of existing code libraries
(libraries in C are collections of c functions, ready-made programs that can be added to any program, like modules)
- adopt a sensible set of coding conventions. Follow a style format consistently.
A program runs regardless of what style a programmer uses or whether he uses one at all, but readability, edit-ability and maintenance are highly benefited with a consistency in writing style.
- avoid tricks or unnecessarily complex code, which can be done easily with C. Use methods that are concise but still understandable
- stick to standard C and do not use classic C (K&R)
In 1996 there were only two versions available.
- avoid non-portable features, to ensure cross platform compatibility
Insights from the Q&A
- Besides C also Pascal, Ada and Modula-2 are also decedents from Algol 60
In the book these other languages are called modern languages, but by 2025 these are all obsolete.
- lint debugger is a standard UNIX utility
- King says that lint is better than gnu gcc compiler to debug C programs
Will check if this is still true in 2025.
- 'bounds-checkers' and 'leak-finders' are other tools that can help with writing reliable C programs.
A bounds-checker checks C array subscripts and a leak-finder helps locating 'memory leaks. Memory leaks are blocks of memory that are dynamically allocated but never de-allocated.