Articles > An Introduction to GCC - interview with the author
24 May 2004
Brian Gough is the author of "An Introduction to GCC" (ISBN 0-9541617-9-3), a tutorial guide to the GNU C and C++ compilers. In this interview he talks about the writing of the book and programming in C and C++.
For more information, visit the webpage for the book itself.
How did you get the idea for the book "An Introduction to GCC"?
As one of the maintainers of the GNU Scientific Library, I was seeing questions posted on the mailing lists by users having problems compiling programs with gcc and g++. It seemed that people were encountering a lot of difficulties in that area, and the causes were often relatively simple (such as a missing header file, or incorrect path).
I realized that there was not really a good tutorial on the subject, only some webpages (which didn't give much detail), or advanced books such as the GCC Reference Manual, which are somewhat intimidating for beginners. Like other developers, I myself had picked up the knowledge of various trouble-shooting techniques, such as using the gcc -Wall or gcc -v options, over many years. I decided I ought to pass this information on, as many of the "tricks of the trade" weren't obvious to the beginner. One example of this is that there are plenty of books on C and C++, but very few about gcc or g++ itself, even though learning how to use the compiler is at least half the battle of learning C and C++ programming.
Personally, I think that the one of the best books for learning the C language itself is Kernighan and Ritchie's classic "The C Programming Language" (the ANSI/ISO edition). For C++, the best book is probably Bjarne Stroustrup's "The C++ Programming Language", assuming that the reader is already familiar with C. I've tried to make An Introduction to GCC a useful supplement to these, covering the compiler-specific topics that can't be covered in general books like K&R or Stroustrup.
What was the process of writing the book?
It took about 3 months to write the main text itself, and another 6 months to edit it into shape and finally produce it. The hardest part was preparing the examples---it was a lot of work to find the simplest cases that demonstrate a problem without any extraneous issues, and without introducing material that was going to be covered in later chapters.
For the editing, I had great help from Dr. Gerald Pfeifer, who works for SUSE in Germany and is closely involved in GCC development. He kindly agreed to review the entire book and made many useful suggestions and corrections that improved it a lot. He also recommended a couple of other experts to me, including his colleague at SUSE Andreas Jaeger, one of the maintainers of the GNU C Library, and David Edelsohn at IBM, the maintainer of the POWER/PowerPC support in GCC. Their input was also very useful.
What is your background in free software?
Originally I was a physicist, doing large-scale numerical simulations. I worked at Fermilab and Los Alamos National Laboratory for a number of years. Free software was heavily used in this environment for many reasons, but a major practical one being that it provided good cross-platform support so that you could set up the same environment on different systems. This is when I first got into C programming, using GCC.
Around that time, I also went to the first Free Software Conference organised by the Free Software Foundation (FSF) in Boston, and began to decide that free software was what I wanted to work on. This eventually led to me joining the GNU Scientific Library team. Later, I returned to the UK and worked on various software development contracts in industry. However, I continued to work on the GNU Scientific Library in my own time, since I thought that the library was a useful thing that should exist and numerical programming was something I could do well and enjoyed, particularly in C.
What was your approach to writing this book on GCC?
I like to keep things simple and short. Judging by their size, a lot of computer books seem put quantity before quality. Personally, I don't think explaining something at length makes it any easier to understand. In my experience, a short explanation is the best. Most ideas in software are pretty simple, and it shouldn't take more than one or two examples to demonstrate them---in particular, the actual text of An Introduction to GCC is less than one hundred pages, but covers all the main topics.
Another aspect of my approach is that I believe in professionalism in software development, by which I mean that programming is best done by those have chosen to pursue it and care about the quality of their work. This is especially true in C and C++ programming, which require a high-degree of attention to detail to achieve good results. So in terms of writing, I don't believe in dumbing things down. For C and C++ programmers, this means that it's necessary to understand the concepts of object files, assembly language, etc and their connection to the hardware. I don't think people can program well in languages like C or C++ without an understanding of the lower-level concepts, so I've made sure these are explained at the appropriate points in the text. Secondly, it's also important that programmers should be introduced at an early stage to the relevant standards, such as the ANSI/ISO standards for C and C++, or the POSIX standards for Unix. A good knowledge of standards is a key skill for a professional developer, as they provide a solid foundation to their understanding of the language, and are crucial for writing portable software.
What is your view on software in general?
In terms of programming generally, I have the same approach as in writing: complexity is the problem, so keeping things simple and small is the solution---I don't claim any expertise in software engineering, but I'd say that a reliable working solution to 75% of a problem is a lot better than an unreliable or non-working solution to 100% of the problem. From my experience of different systems over the years I'd much prefer a simple program that works, such a command-line tool, than a complex one that is never completed or is unreliable.
What are your plans for future related books after An Introduction to GCC?
This particular book covers the C and C++ compilers gcc and g++, but GCC also supports a number of other important languages such as Java, Objective-C and Fortran. Nearly all the information in An Introduction to GCC---such as warning, optimization and debugging options---also applies directly to these languages too, but there are some language-specific features that I wasn't able to cover in this volume, as I didn't want to make it too long. I am thinking about those for future volumes. The GNU Compiler for Java gcj is really coming along these days, and can be used to compile major Java applications. There is also a lot of renewed interest in Objective-C from its use on the latest Macintosh systems, and this has been supported for a long time in gcc. We're also bringing out a tutorial on the GNU version of the Unix Bourne shell, bash, titled An Introduction to GNU Bash, which will cover use of the shell (such as setting up personal login files), and simple shell-scripting. Readers of An Introduction to GCC might also be interested in our existing book Comparing and Merging Files with GNU Diff and Patch (ISBN 0-9541617-5-0), which explains how to manipulate different versions of a project's source files.
Where did you find the cover image for the book?
The cover image shows part of a silicon chip layout, which was created by Steven Rubin of Static Free Software, using the Electric VLSI design program. I was looking for an image that was created using free software, and was thinking of something "low-level", such as a chip design, which could be associated with C programming. After searching the FSF's Free Software Directory, I came across the design program "Electric", which is a GNU package with a long history going back many years, and has been used in many applications in industry. I was glad to feature it on the book, as it is a good example of how free software can be used for major projects, where an organization needs complete control over its processes.
What would be your top tips for new C programmers?
Off the top of my head, for GCC, I'd say always use the -Wall warning option to enable warnings. This is surely the most important option in GCC. For general C programming, a good rule of thumb is to make sure every malloc has a corresponding free. It is surprising how often I have seen a memory leak in a big program that can be found by the simple trick of observing that there is one more malloc than free in a function somewhere. I guess another point would be to always turn on the -g debugging option for any executables that you distribute, because you never know when you might need it. For any more tips, you'd have to see the book An Introduction to GCC itself though---I tried to include all the GCC-related tips that I know there.
Bibilographic details:Title: "An Introduction to GCC"
Author: Brian J. Gough
Published by Network Theory Ltd, May 2004
Paperback (6"x9"), 124 pages
Retail Price: $19.95 (£12.95 in UK)