Author: Ben Klemens
Audience: All C programmers apart from complete beginners
Reviewer: Mike James
A C fit for this century? How different could it be?
I learned C from K&R and so as you might expect the idea of checking that my current practice is up to date is something I like.
Over time my usage of C has changed, but essentially my understanding of the language does derive from the way I know it maps to assembler. For example, I understand that an array and a pointer are roughly the same thing. I also know why pointer arithmetic works like it does because I understand the way storage mapping functions work.
What I have noticed is that many programmers who have been introduced to C in recent times don't understand what is going on under the hood and hence often find C's semantics a bit strange. A 21st century understanding of C would therefore seem to be one that doesn't relate as deeply to the machine code that is produced.
In the first five chapters, which constitute Part I - The Environment, Ben Klemens get to grips with another big change. Over the years I have used a few C compilers but I have never had to deal with the sort of tools covered in the first two chapters. Partly because most of the C programs I write are comparatively short and you can get by with a compiler, editor and linker, or perhaps these days with a little luxury like Eclipse or Netbeans IDEs.
The first chapter focuses on POSIX v non-POSIX compilers, makefiles and using libraries from source. Then on to debuggers and unit testing. Chapter 3 explains packaging with the shell v make and Chapter 4 explains version control using Git. A lot of these considerations are wider issues than just C. The final chapter of the section was the most interesting to me as it covered issues of dynamic loading and how to wrap C functions so that they can be used by other languages - the example is in Python.
Part II - The Language is really what I wanted to read the book for. Part I is interesting enough but finding out if C should be written in a modern style is really what the title of the book promises.
Chapter 6 gets off to a "traditional" start with a look at pointers and how they work with memory management. This is traditional because it has been at the core of C since it was invented. If you know about the stack and heap and can use malloc reasonably well there is little new here apart from an emphasis on a more general use of pointers. There may be nothing new but if you are even slightly hazy on how pointers and memory allocation work this is a good introduction.
Chapter 7 has a provocative title "Inessential C Syntax that Textbooks spend a lot of time covering". The first suggestion is "don't bother returning from main". OK, I know that if you don't include a return it is assumed that you are returning zero, which is a no-error indicator, but why would I want to avoid typing return 0?
The next suggestion is that you should put all of your declarations close to where the variables are first used. Not everyone will agree with this recommendation. From here we have a collection of interesting observations - don't cast the return pointer from malloc because these days its a void, done use enums, do use gotos and other direct jumps, prefer double to float and so on. All well argued and you don't have to agree with all of them.
Chapter 8 is the flip side of chapter 7 - Important C Syntax that textbooks often do not cover. Topics include macros and the preprocessor in general, how to figure out what static and extern are all about, and what exactly does const make constant.
Chapter 9 discusses string handling - always a minefield, even if C strings are simple in their conception. The last part of the chapter deals with Unicode, which is one of the features that probably really is 21st century as it grows in importance. Chapter 10 does for structs what the previous chapter did for strings. In this chapter we meet the perceived problems with typedefs - anyone for Hungarian notation?
Chapter 11 might make you think that you had fallen into a different book - Object-Oriented Programming in C. No there aren't two + signs missing. C has the power to be used in an object oriented like way without the extensions C++ added. For example a struct can have pointers to functions and these can be treated as methods. The explanation in this chapter goes a lot further and almost reinvents in a raw form the things that C++ added to make objects easier - vtable as a table of function pointers, for example.
From this point the book starts to focus in its final two chapters on particular "side" technologies. First we have parallel threading in Chapter 12 via the OpenMP library and PThreads. Chapter 13 is just titled "Libraries" and it surveys common libraries - Glib, Posix, Gnu scientific and SQLite.
Despiute its title, this is not a book to take you into 21st Century C, I'm not convinced such a thing exists, as the main concerns of the book have been important since the early days of C. Perhaps it is just that we have had more time to think about them and use the tweaks that the language revisions have provided. Writing good C has always had the same objectives.
If you are fairly good a C programming then read this book to be even better. It is full of intermediate to advanced ideas. Personally I still think that C seems a lot easier and a lot more logical when you know how it relates to the machine architecture it was designed to mimic. I guess that this is the sense in which the book is 21st century in that this knowledge is becoming increasingly scarce.
Recommended to every C programmer but the very beginner.
SQL Queries For Mere Mortals, 3e
Authors: John Viescas and Michael J. Hernandez
Publisher: Addison Wesley, 2014
Aimed at: Anyone wanting to learn or improve SQL
Reviewed by: Kay Ewbank
While it may sound as though it's aimed at people who don't know SQ [ ... ]
Developing Quality Technical Information
Authors: Michelle Carey, Moira McFadden Lanyi, Deidre Longo, Eric Radinski, Shannon Rouiller, Elizabeth Wilde
Publisher: IBM Press
Audience: Those who produce technical documentation
Reviewer: Kay Ewbank
[ ... ]